Topic: Best practices for storing private keys on server? (Read 1096 times)
HIDE YOUR KEYS
I agree on the completely separate machine the runs bitcoind. Behind a firewall, or behind a nat, and a completely fresh blank machine.
If you have staff who work for you, the machine can even be offline. Maybe use some form of offline transaction signing thing.
There just has to be a secure way to communicate to the private bitcoind server securely, and there are many methods for that. The software waits for your go signal before signing.
This go ahead signal can come from another computer (your personal laptop), or even a mobile device or a cell phone. You're supposed to see the transaction before it gets broadcast to the network.
If you have staff who work for you, the machine can even be offline. Maybe use some form of offline transaction signing thing.
There just has to be a secure way to communicate to the private bitcoind server securely, and there are many methods for that. The software waits for your go signal before signing.
This go ahead signal can come from another computer (your personal laptop), or even a mobile device or a cell phone. You're supposed to see the transaction before it gets broadcast to the network.
To prevent a website hack from emptying the "front line" wallet, it may be best to write a very simple API that runs on the bitcoind machine, sanity checks any spending requests from the web site machine, and if valid invokes bitcoind locally.
I've been contemplating the same, and have come up with the following ideas:
1. Run bitcoind on a separate machine to your website. Have the website connect to the bitcoind machine via the JSON API as a client. Keep the bitcoind machine as locked down as possible. Keep its existence private. Run as little software on it as possible to reduce the risk of security holes - basically just bitcoind, sshd (so you can log in), and whatever monitoring software (zabbix, nagios, etc) you run. Keep its software up to date.
2. Keep only the minimum balance needed to fulfil short-term spending (say in the next day or two) on the bitcoind machine. Send the rest to another bitcoin account elsewhere (call it the "archive").
3. Do any large spending (over X bitcoins) manually as a batch job once a day, perhaps on the "archive" bitcoin machine. This allows you to keep the balance on the "front-line" bitcoind machine lower.
Any other ideas?
1. Run bitcoind on a separate machine to your website. Have the website connect to the bitcoind machine via the JSON API as a client. Keep the bitcoind machine as locked down as possible. Keep its existence private. Run as little software on it as possible to reduce the risk of security holes - basically just bitcoind, sshd (so you can log in), and whatever monitoring software (zabbix, nagios, etc) you run. Keep its software up to date.
2. Keep only the minimum balance needed to fulfil short-term spending (say in the next day or two) on the bitcoind machine. Send the rest to another bitcoin account elsewhere (call it the "archive").
3. Do any large spending (over X bitcoins) manually as a batch job once a day, perhaps on the "archive" bitcoin machine. This allows you to keep the balance on the "front-line" bitcoind machine lower.
Any other ideas?
Sorry if this question has been asked before--I tried searching the forums, and I haven't found anything yet. I'm in the first phases of starting a website that will handle bitcoins, and I'm not sure what the best practices are for storing a private key. I don't know too much about security, but I know what hashing is and I understand in a vague sort of way how private keys/public keys/addresses are generated and how they work together. So with that in mind, I have a few questions:
- What is the "most" secure way to store private keys, without putting them in cold storage? I'm assuming just throwing them in an sql table isn't the best thing...
- Let's say I send bitcoins to an address, and a server somewhere in the world has the private key to this address, and manages the funds. How would an attacker find the server to attack it in the first place? Is there any way I could completely "hide" the server's location while still making transactions from it, thereby protecting it from attacks?
- Another thought I had: Say I have the server generate a private key, give half of it to the user, and then store only the other half. The user could submit his half of the key at a later date, and the website could make transactions and then forget the user's half again. It seems like this would protect relatively well against attacks, as an attacker would need to get both pieces of information in order to do anything. Of course, the user must trust both that the server isn't storing the full key and that the server will always be acting in the user's interest; other than this drawback, is there some reason this implementation is a bad idea?
Thanks in advance for any replies!
- What is the "most" secure way to store private keys, without putting them in cold storage? I'm assuming just throwing them in an sql table isn't the best thing...
- Let's say I send bitcoins to an address, and a server somewhere in the world has the private key to this address, and manages the funds. How would an attacker find the server to attack it in the first place? Is there any way I could completely "hide" the server's location while still making transactions from it, thereby protecting it from attacks?
- Another thought I had: Say I have the server generate a private key, give half of it to the user, and then store only the other half. The user could submit his half of the key at a later date, and the website could make transactions and then forget the user's half again. It seems like this would protect relatively well against attacks, as an attacker would need to get both pieces of information in order to do anything. Of course, the user must trust both that the server isn't storing the full key and that the server will always be acting in the user's interest; other than this drawback, is there some reason this implementation is a bad idea?
Thanks in advance for any replies!
Jump to: