I'm working on a service which will require me to store bitcoin payout addresses in my database. This means that a potential attack to my service would be to gain access to the database and replace the addresses in the database with the attacker's bitcoin address so that payouts can be automatically sent to him/her.

My users will be have multiple social accounts linked to my service (Facebook, Google, LinkedIn, etc.) and they will log in with a password (which is stored as a hash). The database I'm using is MySQL, so I'm wondering if I can put any restrictions on the bitcoin address column which would require some type of validation of the bitcoin address in order to ensure that somebody hasn't just gone into the DB and put in a bitcoin address of their own. Maybe I can include some kind of a hash which validates the address with the user somehow and allows me to check the address and the hash before a payout is sent, if they match then I can send a payout.

Any other approaches to securing the address?

4 Answers 4


If an attacker has write access to your database without you noticing immediately, it's pretty much Game Over.

Say you are actually able to secure the payout address field from tampering, then the attacker could still overwrite the password field with his own hash, log in as the user and change the payout address through the "allowed" way.

You should not worry too much about this scenario, but rather make sure no one will get direct access (read or write) to your database in the first place: Use prepared statements, grant minimum required access, harden your servers, etc.


I've spoken with a DB at work and here are the suggested ideas:

  • Save a hash of each bitcoin address which is hashed with a password (the password should not be accessible through the database).
  • Make triggers on the database column: whenever the record is changed, the trigger would execute and the changes will be recorded in a change log table.
  • Whenever the user makes changes to their personal information we would send them an e-mail and log the change into the change log table.

The benefits of the above logs is that we will have multiple places where we can track changes and if there is some type of a discrepancy, we can track it appropriately.

The way it's going to work when a payment needs to be made:

  • Use the password to hash the bitcoin address on file and compare it against the corresponding bitcoin address hash.
  • If the addresses match, then we can make a payment to the address. Otherwise, an alert will be triggered.

I still see another weakness here: if we use the same password to hash every bitcoin address, then it may become easier to crack the password if somebody takes a bunch of the hashed bitocin addresses from the database. However, this is still a much better solution than not doing anything to verify the bitcoin addresses.

  • How could they have access to the db but not to the password?
    – o0'.
    Commented Jan 17, 2013 at 8:14
  • @Lohoris the password will be something that will only exist in the application that's interacting with the DB. If an attacker somehow gets access to the DB, it is less likely that they would have also gained access to the app settings. The password would probably be encrypted and stored in the application settings. Again, not an ideal solution, but it just eliminates the less determined attackers, IMHO.
    – Kiril
    Commented Jan 17, 2013 at 14:06

You can always sign the address in the database, but you must be careful about it. When the user register you would to verify their info, sign their address on an offline computer (with an offline private key) and put both of them in different field in the database. Then when you take the address in the database you verify that the signature can be verified with your public key.

That way if someone temper with the database they shall not be able to forge an valid signature (because your private key is offline and protected) and when a signature is not valid it calls an alert. You must be careful that the verification is made by your public key.

The bitcoin client supports signature with any addresses.

And in anyway you should really try to secure your database, have a low privilege user for the program that uses the database, do not give any access to other than you and your trusted employees. And secure the physical access to the server.


Does the payout have to be automatic, or can it be user-triggered?

In the latter case, you can choose not to store the payout address at all, instead prompting the user for it every time he decides to receive it.

Of course if you get hacked, you failed no matter which procedure you choose, so this is kind of a moot point.

  • The payout is automatic: my service receives bitcoins and I distribute payouts to all of the bitcoin addresses on file.
    – Kiril
    Commented Jan 16, 2013 at 22:46
  • And yes, if we get hacked we're in trouble, but I just want to take as many precautions as possible. The more doors we have, the less likely that we'll get compromised. I'm also aware of the concept of weakest point :).
    – Kiril
    Commented Jan 16, 2013 at 22:55
  • 1
    @Lirik since you don't know what they hacked if they hacked, it's a yes or no situation.
    – o0'.
    Commented Jan 17, 2013 at 8:12
  • +1, you are correct that if I get hacked, then the damage could be big, but I would think that it's better to have several layers of security. There is only so much I can do to guard against an attacker given the resources we have, but I feel like these are fairly inexpensive things that would help us get some protection until a more robust solution can be provided. I'm open to other suggestions too.
    – Kiril
    Commented Jan 17, 2013 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.