<p>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 </p>

CC BY-SA 3.0
2017-07-24T06:43:26.690Z
2017-07-24T06:43:26.690Z
Haddar Macdasi
<p>The precautions you can take from an architerual point of view would be as follows:</p>

<ul>
<li>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).</li>
<li>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.</li>
<li>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. <a href="https://www.bitgo.com/info/" rel="noreferrer">Bitgo</a> enforces multisig coupled with HD in a secure way to provide similar services. </li>
</ul>

<p>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. </p>

CC BY-SA 4.0
2018-06-21T12:46:49.750Z
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
CC BY-SA 4.0
2018-06-22T14:44:07.673Z
Yes, very good point, which was exactly the intention of involving a user-provided password in the encryption scheme :)
Daniel Valland
CC BY-SA 4.0
2018-06-21T12:29:24.797Z
2018-06-21T12:29:24.797Z
Shabahat M. Ayubi
<p>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 &amp; 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: <code>ENCRYPT(HASH(hard-coded password+user password+random salt+pepper),  private key)</code>.</p>

CC BY-SA 3.0
2017-07-24T11:11:33.893Z
I'm sure two factor authentication is something you've considered already too?
Josh
CC BY-SA 3.0
2017-07-24T13:49:58.600Z
@Josh  Yep, I was thinking possibly using an extra security pin, or possibly just email verification..
Daniel Valland
CC BY-SA 3.0
2017-07-25T08:24:04.713Z
Cool. Google authenticator pretty good. SMS worst ;)
Josh
<security><server><coldstorage>
How to securely store Bitcoin server-side?
Daniel Valland
# How to securely store Bitcoin server-side?

(Asked by: username_0 on 2017-07-23)

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)`.

**Tags:** security, server, coldstorage

> **Comments:**
> **username_1**: I'm sure two factor authentication is something you've considered already too?  
> **username_0**: @username_1  Yep, I was thinking possibly using an extra security pin, or possibly just email verification..  
> **username_1**: Cool. Google authenticator pretty good. SMS worst ;)  

---

## 2 answers

### Answer by username_3 on 2018-06-21. Score: 5 | Accepted answer

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](https://www.bitgo.com/info/) 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.

> **Comments:**
> **username_4**: 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.  
> **username_0**: Yes, very good point, which was exactly the intention of involving a user-provided password in the encryption scheme :)  

---

### Answer by username_2 on 2017-07-24. Score: 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


---

