1

I am working on a web application that needs to hold users Bitcoin for an extended amount of time (escrow-like scenario), and I was wondering what are some good steps/precautions and principles (dos & dont's) to do this securely. This is mostly in regards to security, so things like individual vs single server-side wallet etc. My thoughts thus far is that I probably should not have all the eggs in one basket, so something like generating a new random wallet per transaction server-side, and encrypt the private keys with a two-way algorithm before they are stored in the database, perhaps combined with user password so given the encryption function ENCRYPT(password,data) it would be: ENCRYPT(HASH(hard-coded password+user password+random salt+pepper), private key).

  • I'm sure two factor authentication is something you've considered already too? – Josh Jul 24 '17 at 11:11
  • @Josh Yep, I was thinking possibly using an extra security pin, or possibly just email verification.. – Daniel Valland Jul 24 '17 at 13:49
  • Cool. Google authenticator pretty good. SMS worst ;) – Josh Jul 25 '17 at 8:24
4

The precautions you can take from an architerual point of view would be as follows:

  • The database storing the private keys or the seeds in case of HD wallets should be running on a separate instance and only accessible via the application server(AWS allows lots of configuration you can make in the virtual private cloud i.e. VPC to accomplish this).
  • The keys are encrpyted. As you mentioned some sort of 2 way encryption key needs to be maintained. Also it should be your motive to achieve minimal responsibiltiy in case of breaches. So encrypting private keys with users password is a good start. But storing plain text passwords in obviously stupid and so is getting it from the user over the network. https solves the over the network issue but plain text password itself is a point of failure. So you will have to come up with a different scheme where in you are unable to spend your users funds.
  • Going by the same minimisation of your risk approach, multisig would be the best solution in this case. But this will require your users to be more active in the transaction process. Bitgo enforces multisig coupled with HD in a secure way to provide similar services.

In conclusion, HD wallets will reduce the number of keys you have to store, having a separate private key server instance and encrypting the private keys by the users passwords is a good way to start. Multisig would make things complicated for the user but would provide utmost security.

  • A fine point, if you are unable to spend your user funds it should be nearly as hard for anyone else (an attacker) to do so. – Willtech Jun 21 '18 at 12:46
  • Yes, very good point, which was exactly the intention of involving a user-provided password in the encryption scheme :) – Daniel Valland Jun 22 '18 at 14:44
1

You can use HD wallet, generate the master key on local machine ,after that with the master public key you can generate any amount of public keys. That's one possibility You can also use bitcoin qt and generate for each request and once in awhile withdrawal to a cold storage

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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