One of the suggested security precautions 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?

  • 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. – Abdussamad Jan 29 at 8:26
  • @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 Jan 29 at 18:37

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.

  • 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 Jan 29 at 8:29
  • "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 Jan 29 at 18:40
  • @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 Feb 1 at 8:51
  • @Abdussamad so bitmex reviews and process each withdrawal request manually? Seems like a ton of work.. – S.O.S Feb 1 at 18:21
  • @S.O.S Nah. Download a list of requested withdrawals, run a script to audit for inconsistencies, then sign the withdrawal. Pretty straightforward. – ieatpizza Feb 1 at 21:12

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.