op,
You need to check HD wallets concept. As @buwaytress has correctly reminded you don't need a separate key pair/wallet for each user/invoice, a single HD wallet could generate as many receiving addresses as you wish, feel free to store them in your database for further accounting references and keep the private key secure/off-line/cold. Good luck.
Topic: Storing private keys on servers - page 2. (Read 529 times)
If you want 'instant' withdrawals:
- Make use of 2 wallets (hot- and cold wallet)
- Only keep a limited amount on your hot wallet (on the web server). It has to be an amount which you can afford to lose in case of an attack.
- Top it up with your cold wallet funds when necessary.
- Make use of 2 wallets (hot- and cold wallet)
- Only keep a limited amount on your hot wallet (on the web server). It has to be an amount which you can afford to lose in case of an attack.
- Top it up with your cold wallet funds when necessary.
If his customers are fine with delayed withdrawals, then what you proposed is the most suitable solution.
But if they need instant withdrawals and full control over their funds (not possible with hot/cold solution), then you may consider this solution:
-generate a private key for each user
-save the private keys (plain text) on an offline database
-encrypt private keys with a random key for each user
-save the encrypted private keys on the server's database
-give the user the key needed to decrypt his private key
This way, your customer will be able to use his private key without knowing it and it will be safe in cas the server gets compromised.
Did I misunderstand something or am I seeing something OP is saying: that for every user, he is creating a new wallet and new set of private keys? To my understanding most online services are actually only using 1 wallet (or a set of wallets) and therefore just the 1 set of private keys (or a few for a few sets of wallets). Every client gets a unique address, but they actually all belong to the same wallet, hence individual deposits get batched up and can be combined to process other client withdrawals.
So if OP is indeed creating a unique WALLET for each customer, then why not make it so you only issue them addresses from fewer wallets?
OR make their private key their responsibility (as should anyway be the case?)? It's sort of a win-win. They keep their own keys, you also de-risk.
Apologies in advance if I've veered off the reserve!
So if OP is indeed creating a unique WALLET for each customer, then why not make it so you only issue them addresses from fewer wallets?
OR make their private key their responsibility (as should anyway be the case?)? It's sort of a win-win. They keep their own keys, you also de-risk.
Apologies in advance if I've veered off the reserve!
OP,
FFS man, do not store your private keys on an online server. Keep them on a hardware wallet, USB stick or paper wallet. Don’t risk storing them anywhere that somebody could gain access to.
Your idea sounds like a nightmare waiting to happen. You’re clearly tech minded so you’re not a stupid guy. Common sense is priceless though, treat your private keys like you would the most valuable thing you own - i.e. away from everybody else.
FFS man, do not store your private keys on an online server. Keep them on a hardware wallet, USB stick or paper wallet. Don’t risk storing them anywhere that somebody could gain access to.
Your idea sounds like a nightmare waiting to happen. You’re clearly tech minded so you’re not a stupid guy. Common sense is priceless though, treat your private keys like you would the most valuable thing you own - i.e. away from everybody else.
Really Thanks for such a quick and valuable responses Pmalek, bob123, NeuroticFish and mocacinno. I'll look into this. The gist is either prepare for the hack using hot wallets or compromise the user experience over security using cold wallets.
I'm learning to be a security-minded developer and definitely be the one with the help of you peoples.
I'm learning to be a security-minded developer and definitely be the one with the help of you peoples.
I agree for 100% with bob123, NeuroticFish and Pmalek, do not store private keys, seeds, xprv's,... on an online machine.
However, i did wanted to add one remark: there seems to be a misconception about hashicorp's vault in your OP: if you're storing the unseal keys or root tokens on your online machine, you're doing it wrong... But i do have to agree that IF you unsealed your vault AND your system gets compromised AND the hacker gets his hands on your machine AND a token (or user/pass or...) he will be able to get your private keys from your server if you were storing them in vault... It's the chicken or the egg dilemma, if you want your scripts to be able to access your private keys directly, a hacker will always have a loophole to do thesame. So your best sollution would be not to store your private keys on an online machine
There are tons of exchanges that had excellent programmers and security audits and strict procedures but still got abused in the end... Don't make the mistake of thinking you're better than those exchanges!
However, i did wanted to add one remark: there seems to be a misconception about hashicorp's vault in your OP: if you're storing the unseal keys or root tokens on your online machine, you're doing it wrong... But i do have to agree that IF you unsealed your vault AND your system gets compromised AND the hacker gets his hands on your machine AND a token (or user/pass or...) he will be able to get your private keys from your server if you were storing them in vault... It's the chicken or the egg dilemma, if you want your scripts to be able to access your private keys directly, a hacker will always have a loophole to do thesame. So your best sollution would be not to store your private keys on an online machine
There are tons of exchanges that had excellent programmers and security audits and strict procedures but still got abused in the end... Don't make the mistake of thinking you're better than those exchanges!
Since you are custodian for the funds, you don't need private key for each user. Each user will have its own receiving address. The sending happens from the wallets that suits you best.
Sending the funds has to be batched for the sake of network, for making the tx fees smaller and for double checking them. And you'll clearly need cold storage too.
Sending the funds has to be batched for the sake of network, for making the tx fees smaller and for double checking them. And you'll clearly need cold storage too.
Don't store them on your online server.
If you can allow to delay payouts / withdrawals by a few hours:
- Create a 2-server-setup with one being your webserver and one being 'offline'.
- Make use of 2 wallets (hot- and cold wallet)
- Every X hours batch the transactions, verify them, do sanity checks, and create a payment request to your 'offline server'.
- Your 'offline-server' should then handle all payments (make sure to secure it with a firewall and only allow specific incoming requests from your webserver + outgoing requests to broadcast the transactions) from the hot wallet.
- Top up the hot wallet with the cold wallet funds when necessary (manually) or withdraw from the hot wallet to the cold wallet (automatically).
If you want 'instant' withdrawals:
- Make use of 2 wallets (hot- and cold wallet)
- Only keep a limited amount on your hot wallet (on the web server). It has to be an amount which you can afford to lose in case of an attack.
- Top it up with your cold wallet funds when necessary.
But generally:
If you are going to build a trading platform yourself (without developer who build the whole software with security in mind (from the very beginning)), you are guaranteed to have vulnerabilities.
And these vulnerabilities will be exploited if it is worth it for the attacker.
If you really want to build a professional platform and need to handle funds of users, hire some competent security-minded developer.
It is not going to be cheap, but it will save you a lot of money in the long run (given that you really want to build a professional platform).
If you can allow to delay payouts / withdrawals by a few hours:
- Create a 2-server-setup with one being your webserver and one being 'offline'.
- Make use of 2 wallets (hot- and cold wallet)
- Every X hours batch the transactions, verify them, do sanity checks, and create a payment request to your 'offline server'.
- Your 'offline-server' should then handle all payments (make sure to secure it with a firewall and only allow specific incoming requests from your webserver + outgoing requests to broadcast the transactions) from the hot wallet.
- Top up the hot wallet with the cold wallet funds when necessary (manually) or withdraw from the hot wallet to the cold wallet (automatically).
If you want 'instant' withdrawals:
- Make use of 2 wallets (hot- and cold wallet)
- Only keep a limited amount on your hot wallet (on the web server). It has to be an amount which you can afford to lose in case of an attack.
- Top it up with your cold wallet funds when necessary.
But generally:
If you are going to build a trading platform yourself (without developer who build the whole software with security in mind (from the very beginning)), you are guaranteed to have vulnerabilities.
And these vulnerabilities will be exploited if it is worth it for the attacker.
If you really want to build a professional platform and need to handle funds of users, hire some competent security-minded developer.
It is not going to be cheap, but it will save you a lot of money in the long run (given that you really want to build a professional platform).
The safest way would be not storing them on any server at all. Sorry for going a bit off topic but I wouldn't trust a random site with my private keys. You explained the reasons yourself. They can be hacked or obtained by a malicious third party.
Hi, I'm newbie in crypto world and working on a tranding platform. I've to generate separate addresses against every user and stuck at how to securely store the private keys. I've looked into the ecc encryption, AWS KMS, and hashicorp vault but the common thing among all the methods is, the decryption password or token is still stored on the server. So if the server got compromised everything is gone. Now my question is what is the best way to store the private keys. Thanks!
Jump to: