<p>Usually we try to discourage storing private keys on a server at all unless absolutely necessary.</p>
<p>However, if necessary, just having the keys on a separate server increases the complexity of the attack, as it's an extra step. But, in addition to that, you may employ things like rate limits, limits on transaction size, whitelists on addresses that can be sent to, etc. If there is unusually high transaction volume, a site operator could be notified to step in and review the activity log. In essence, you're right, such a system does have the risk of a hacker who has completely exploited the application server just using the application server to forward requests. But we can slow them down to limit the extent of possible damage.</p>

CC BY-SA 4.0
2021-01-29T08:29:49.543Z
you can also harden the key server because it will run a reduced set of software compared to the app server or web server.
Abdussamad
CC BY-SA 4.0
2021-01-29T18:40:58.657Z
"Usually we try to discourage storing private keys on a server at all unless absolutely necessary" In what scenario would you say it is not necessary to store the keys? I mean, imagine we're dealing with an exchange or marketplace with hundreds or thousands of withdrawals requests per day is there any other way to process the withdrawals without storing the private keys on a server? It isn't possible to have each request processed manually..
S.O.S
CC BY-SA 4.0
2021-02-01T08:51:54.613Z
@S.O.S if you're running an ecommerce site where you just need to receive payments online while spending the money can be done manually then you can take advantage of the properties of bip32 extended public keys to generate receive addresses without letting the server spend the coins sent to them. as for the scenario of an exchange or marketplace you can manually do withdrawals once a day like bitmex does.
Abdussamad
CC BY-SA 4.0
2021-02-01T18:21:12.777Z
@Abdussamad so bitmex reviews and process each withdrawal request manually? Seems like a ton of work..
S.O.S
CC BY-SA 4.0
2021-02-01T21:12:31.660Z
@S.O.S Nah. Download a list of requested withdrawals, run a script to audit for inconsistencies, then sign the withdrawal. Pretty straightforward.
ieatpizza
CC BY-SA 4.0
2021-01-29T07:48:13.117Z
2021-01-29T07:48:13.117Z
ieatpizza
<p><a href="https://bitcoin.stackexchange.com/a/76482/78451">One of the suggested security precautions </a> when storing Bitcoin of users on a server is to store the private keys on a separate server:</p>
<blockquote>
<p>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).</p>
</blockquote>
<p>I understand that if the PK is stored on a separate server then that server would also need to be compromised in order for the security of the actual keys to be compromised. However, since presumably, the main server will be sending withdrawal/transfer requests to the &quot;security server&quot; what stops a hijacker from effectively liquidating the entire wallet balance by using the main server to forward requests to the security server? In other words, what is gained by adding an extra server to the equation if the security server is expected to &quot;honor&quot; (and sign) requests it receives from the main server?</p>

CC BY-SA 4.0
2021-01-29T08:26:51.607Z
you should look up what happened between bitfinex and bitgo. bitfinex was relying on bitgo's multisig setup to sign transactions but when finex got hacked the hacker simply sent the requests to bitgo which signed transactions without hesitating. so yes there's no point to it unless you have human oversight and limits placed on signing.
Abdussamad
CC BY-SA 4.0
2021-01-29T18:37:36.220Z
@Abdussamad very interesting (I did not know the hacker used bitfinex's server to forward requests to BitGo making MultiSig essentially worthless in this case) where can I read more about the mechanism of this hack?
S.O.S
<bitcoin-core><wallet><security><private-key><server>
Storing your private key on a "security server"?
S.O.S
# Storing your private key on a "security server"?

(Asked by: username_0 on 2021-01-29)

[One of the suggested security precautions](https://bitcoin.stackexchange.com/a/76482/78451)  when storing Bitcoin of users on a server is to store the private keys on a separate server:

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

I understand that if the PK is stored on a separate server then that server would also need to be compromised in order for the security of the actual keys to be compromised. However, since presumably, the main server will be sending withdrawal/transfer requests to the "security server" what stops a hijacker from effectively liquidating the entire wallet balance by using the main server to forward requests to the security server? In other words, what is gained by adding an extra server to the equation if the security server is expected to "honor" (and sign) requests it receives from the main server?

**Tags:** bitcoin-core, wallet, security, private-key, server

> **Comments:**
> **username_1**: you should look up what happened between bitfinex and bitgo. bitfinex was relying on bitgo's multisig setup to sign transactions but when finex got hacked the hacker simply sent the requests to bitgo which signed transactions without hesitating. so yes there's no point to it unless you have human oversight and limits placed on signing.  
> **username_0**: @username_1 very interesting (I did not know the hacker used bitfinex's server to forward requests to BitGo making MultiSig essentially worthless in this case) where can I read more about the mechanism of this hack?  

---

## 1 answers

### Answer by username_2 on 2021-01-29. Score: 2

Usually we try to discourage storing private keys on a server at all unless absolutely necessary.

However, if necessary, just having the keys on a separate server increases the complexity of the attack, as it's an extra step. But, in addition to that, you may employ things like rate limits, limits on transaction size, whitelists on addresses that can be sent to, etc. If there is unusually high transaction volume, a site operator could be notified to step in and review the activity log. In essence, you're right, such a system does have the risk of a hacker who has completely exploited the application server just using the application server to forward requests. But we can slow them down to limit the extent of possible damage.

> **Comments:**
> **username_1**: you can also harden the key server because it will run a reduced set of software compared to the app server or web server.  
> **username_0**: "Usually we try to discourage storing private keys on a server at all unless absolutely necessary" In what scenario would you say it is not necessary to store the keys? I mean, imagine we're dealing with an exchange or marketplace with hundreds or thousands of withdrawals requests per day is there any other way to process the withdrawals without storing the private keys on a server? It isn't possible to have each request processed manually..  
> **username_1**: @username_0 if you're running an ecommerce site where you just need to receive payments online while spending the money can be done manually then you can take advantage of the properties of bip32 extended public keys to generate receive addresses without letting the server spend the coins sent to them. as for the scenario of an exchange or marketplace you can manually do withdrawals once a day like bitmex does.  
> **username_0**: @username_1 so bitmex reviews and process each withdrawal request manually? Seems like a ton of work..  
> **username_2**: @username_0 Nah. Download a list of requested withdrawals, run a script to audit for inconsistencies, then sign the withdrawal. Pretty straightforward.  

---

