Storing private keys on servers

[zaryabbkh]

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! 

[1714835925]

1714835925

[1714835925]

1714835925

[1714835925]

1714835925

[Pmalek]

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.

[bob123]

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

[NeuroticFish]

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.

[mocacinno]

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!

[zaryabbkh]

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. 

[LFC_Bitcoin]

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.

[buwaytress]

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!

[khaled0111]

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.

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.

[aliashraf]

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.

[franky1]

there is no such thing as "instant pay" in bitcoin. a confirm is ~10mins.
this means without having a private key anywhere on the web server you can still offer a PROMPT service within the acceptable tolerance of 10mins

the easiest method is when a user makes a withdrawal request. this request does not trigger signing a transaction on the webserver, but puts a withdrawal request into a database. and the web server never needs to list a IP address or make and calls out.. instead a remote system can securely look in on the withdrawal request database every 20seconds-2minutes. see what needs to be processed and then process it remotely knowing it will be in a block within the tolerable timescale


thus the webserver has no keys now any listing of the remote system because the webserver does not transmit anything. it just lists items

[PrimeNumber7]

For those who are suggesting to not store private keys on an online machine, for most bitcoin and crypto businesses, this is not an option. The marketplace demands quick withdrawals in most instances with exceptions for large withdrawals.

An online business will, by design, need to store SSL keys online, and this in some ways is similar to storing even cold storage keys online, to an extent, because a hacker can potentially impersonate your website and display deposit addresses for customers that belong to the hacker. In order for this attack to be successful, more than just the SSL keys will need to be compromised.

I generally agree with bob123's comments with regards to only storing limited amounts of coins on your server, and to top off your "hot" wallet when necessary. I would also warn that if your database server is compromised, a hacker may trick you into believing a certain user has a larger balance available for withdrawal than is actually true. This means you will need to independently verify the integrity of your database each time you remove coins from your "cold" wallet; this is true even if you do not keep any coins on an online server.

A good rule of thumb is to not keep more than 1-2 months expected earnings worth of crypto in your online storage so in case your server does get hacked, you can easily "earn" your way out of the losses.

I do not wish to give you specific advice or suggestions on how to protect your customer's money, in large part because I cannot ensure you will hear any of my ongoing advice, and will not be in a position to ensure you are correctly implementing what I am suggesting.

If you do not personally know how to protect your private keys and the integrity of your DB, I would suggest you hire someone who has experience doing this job function who you can independently verify to be an "expert"

[odolvlobo]

Companies that are serious about security use this: Hardware Security Module

[bob123]

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.

Did you even read the OP ? I guess not..

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?

He wants to create one address (implies 1 private key) for each user, as mentioned in his OP.
Not a separate wallet for each user.

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.

Why does the user need the key to decrypt the private key if he doesn't have access to the private key anyway ?
Also, you most likely don't want each user to be able to have access to the private keys. This creates room for exploitation.

The funds of the user are managed in a database and the coins should get consolidated anyway (when the fees are low).

[...]
If you do not personally know how to protect your private keys and the integrity of your DB, I would suggest you hire someone who has experience doing this job function who you can independently verify to be an "expert"

^This.

No system is completely secure.
You need to hire experts which can be made liable in case of an obvious data breach. Not some random online guy.

Vulnerabilities will exist, it is important to have a plan to reduce possible damage and to make sure that the total amount of damage is limited.
For example, it has to be completely bulletproof that an attacker can't add withdrawal requests AND top up the hot wallet from your cold wallet. This would be a disaster.

Companies that are serious about security use this: Hardware Security Module

That's currently not the topic.
Such a module won't help you if an attacker can manipulate the database which handles the withdrawals.

It is necessary to have a good concept, then focus on the hardware you are using.

[zaryabbkh]

Thanks bob123 for such a great clarification.

yeah the issue is I've to generate separate address for each user and in case of ethereum the hd wallets doesn't works like bitcoin where we can just select UTXOs and make a transaction.

bob123 gives the most optimal solution

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.

and if we add this from PrimeNumber7

A good rule of thumb is to not keep more than 1-2 months expected earnings worth of crypto in your online storage so in case your server does get hacked, you can easily "earn" your way out of the losses.

also thanks for pointing out this issue

I would also warn that if your database server is compromised, a hacker may trick you into believing a certain user has a larger balance available for withdrawal than is actually true. This means you will need to independently verify the integrity of your database each time you remove coins from your "cold" wallet; this is true even if you do not keep any coins on an online server.

i'll keep track of all these valuable suggestions and will share the final solution what I've got.

I do not wish to give you specific advice or suggestions on how to protect your customer's money, in large part because I cannot ensure you will hear any of my ongoing advice, and will not be in a position to ensure you are correctly implementing what I am suggesting.

Thanks!

[aliashraf]

yeah the issue is I've to generate separate address for each user and in case of ethereum the hd wallets doesn't works like bitcoin where we can just select UTXOs and make a transaction.

Wrong! HD wallets work just fine for both Ethereum and bitcoin and every other cryptographic system that is based on ECDSA standard. period.

bob123 gives the most optimal solution

No, he does not  
instead of wasting your time by catching up with irrelevant topics like cold vs hot wallets and alike, just focus on the main problem, you need multiple receiving addresses mapped to each user and a single master key to spend from all or not? Decide and choose the right direction....

P.S. say hello to Sh ...

[bob123]

Wrong! HD wallets work just fine for both Ethereum and bitcoin and every other cryptographic system that is based on ECDSA standard. period.

No.

OP is right, you are wrong.

Bitcoin is following a UTXO model, where ethereum has an account model.
This definitely makes a difference.

OP never said that HD wallets do not exist, he said that it works differently when comparing ethereum to bitcoin, which is correct.

bob123 gives the most optimal solution

No, he does not  
instead of wasting your time by catching up with irrelevant topics like cold vs hot wallets and alike, just focus on the main problem, you need multiple receiving addresses mapped to each user and a single master key to spend from all or not? Decide and choose the right direction....

Hot- / cold wallets is an irrelevant topic when hosting an online service which handles user funds?  

The 'main problem' is the mapping from addresses to user ??  


I really don't get what you are trying to say.

If you believe the correct handling of the funds (hot-/cold wallet) is irrelevant, you obviously don't have a clue at all.
And if you additionally think that the mapping is a problem, you absolutely don't know what you are talking about. That is probably the easiest task of creating such a service..


Also, there is no reason to have a 'single master key' to spend funds from.
That's not even possible. You need 1 private for each address. The private keys can be derived using the same seed, but thats not the topic here at all (and won't allow you to spend funds from one 'master key')..

So.. instead of posting bullshit without having any clue, what about you browse through the forum for a few month first (to learn all the stuff you obviously don't know yet) before trying to 'help' someone ?

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

Do you even know how a HD wallet works ?
Not like HD wallets would generate private keys or something silly like that...

Please stop creating post which contain anything 'technical' regarding bitcoin. You are just embarrassing yourself.

[aliashraf]

Wrong! HD wallets work just fine for both Ethereum and bitcoin and every other cryptographic system that is based on ECDSA standard. period.

No.

OP is right, you are wrong.

Bitcoin is following a UTXO model, where ethereum has an account model.
This definitely makes a difference.

OP never said that HD wallets do not exist, he said that it works differently when comparing ethereum to bitcoin, which is correct.

No.

you are trying to justify the wrong credit op gave to you, op claimed that HD wallets are not good because s/he was confused about what the concept is and you are escalating her confusion by talking about utxo vs account model, HD wallet concept is neutral about this issue and we have a lot of both commercial and opensource wallets that support multiple coins including bitcoin and Ethereum you are escalating op's confusion by spreading misinformation. Why? Just because she applauded you ignorantly?

bob123 gives the most optimal solution

No, he does not  
instead of wasting your time by catching up with irrelevant topics like cold vs hot wallets and alike, just focus on the main problem, you need multiple receiving addresses mapped to each user and a single master key to spend from all or not? Decide and choose the right direction....

Hot- / cold wallets is an irrelevant topic when hosting an online service which handles user funds?  

The 'main problem' is the mapping from addresses to user ??  

If instead of trying to show-off you bother to read op's inquiry it is more than obvious that s/he is trying to handle thousands of private keys because s/he is not aware of HD wallets and the feasibility of having one master key and thousands of bitcoin addresses assigned to users, it is why s/he asks about the security of keeping track of so many private keys supposedly on a server using a database.

I really don't get what you are trying to say.

If you believe the correct handling of the funds (hot-/cold wallet) is irrelevant, you obviously don't have a clue at all.
And if you additionally think that the mapping is a problem, you absolutely don't know what you are talking about. That is probably the easiest task of creating such a service..


Also, there is no reason to have a 'single master key' to spend funds from.
That's not even possible. You need 1 private for each address. The private keys can be derived using the same seed, but thats not the topic here at all (and won't allow you to spend funds from one 'master key')..

So.. instead of posting bullshit without having any clue, what about you browse through the forum for a few month first (to learn all the stuff you obviously don't know yet) before trying to 'help' someone ?

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

Do you even know how a HD wallet works ?
Not like HD wallets would generate private keys or something silly like that...

Please stop creating post which contain anything 'technical' regarding bitcoin. You are just embarrassing yourself.

Now you are teaching me HD wallets?

It is really crazy, you give irrelevant information about hot wallet/cold wallet stuff to a confused newbie and s/he says thank you, then somebody tries to really help and you are attacking him because you desperately need the credit? 

Of course there is always a private key corresponding to a public key, the point with HD wallets is that you don't need to store the private keys like what op thinks instead your wallet software derives the corresponding private key from the master private key. You don't need to store this master private key on the server at all because the public keys are not generated using this key but derived from a master public key which is useless for spending funds.

So, op needs to be informed about HD wallets instead of being fooled by your irrelevant poor knowledge about hot wallets and cold wallets.

[zaryabbkh]

First of all lets see how Mnemonic based HD wallets works.

SEED:
time face caught jump pony myth only doll treat clog monitor verify fabric walnut permit

This is the SEED used to generate xpub and xpriv keys for multiple coins, this single key can generate both bitcoin and ethereum addresses and many more, like the hardware walelts Trezor do, 1 single seed is enough for every coin that you stored in your wallet.

BITCOIN XPUB KEY
xpub6DCsNLV4BriXeaACJBxX3ny7vNaegKcJU2W16NKmE6MS8DzXNWj9LgcH647tNhKKDj4GJsamvRR ScD2Sg3bw6JSwJcto4awVGdg5dPM1FTu

path,address,private key for BITCOIN

m/44'/0'/0'/0/0,
197ToSUz1fHUZw6RyayGHcVgAbeMxQu5MN,
L4FSbxSNQdEC32rrwv2CbxEbGeRxP2HrzT6G5JhRUvm6Jri1wp2K

m/44'/0'/0'/0/1,
1H8m2zVwMhEgKJRfDnWsoti1K2kN87x2ym,
L4b7grTtHEtahUNeDLesHTDShRbUTXHp5Jy3Cy4j1YZiVSwLRHXt

ETHEREUM XPUB KEY
xpub6CT1Ak6RQCF4YmYX8X5vKCWMMTp553Mj4LfYEgKidavurq3xcAwnWMspcnEbMz1GLVhqSwgkK7x Y9wqRCBBQieZ7ziRqT5dT6zWiVaga79c

path,address,private key for ETHEREUM

m/44'/60'/0'/0/0,
0xB4d5Eb0A4033770ad5b7076494F5e111BEf0e900,
0xa3ff08362024f18909c7845b38455b3e03ee47e5735977dccc2e50ef825ec1b5

m/44'/60'/0'/0/1,
0x04905Da51b6DDdE795C1890096dDbbfCe3039b0F,
0x81a2fd621dc67aafb6d42791b513a9318eafc01fb63b91afda41c1cd71fc5b21


The issue is ETHEREUM has account model which means every generated address private key is required to make a transaction where as bitcoin has UTXOs model in which we can select multiple UTXOs and make a transaction

197ToSUz1fHUZw6RyayGHcVgAbeMxQu5MN => 0.1 BTC
1H8m2zVwMhEgKJRfDnWsoti1K2kN87x2ym => 1 BTC

so in Bitcoin i can use all 1.01 BTC in a single transaction by just using a function getUTXOs() rest is done by Bitcoin wallet. BTCD or BITCORE gives this functionality.

0xB4d5Eb0A4033770ad5b7076494F5e111BEf0e900 => 0.1 ETH
0x04905Da51b6DDdE795C1890096dDbbfCe3039b0F => 1 ETH

in case of ethereum to use a total of 1.01ETH in my HD wallet i've to individually use both addresses private key to make a transaction and then executing a batch transaction will do the job.


So the problem is not HD wallets its about the architecture of both Bitcoin and Ethereum

I can use a single SEED and xpub key to generate unlimited addresses of ETHEREUM but i can't make transactions like BITCOIN i'll need the private key of all the generated addresses.

To automate the withdrawal process we have to store private keys on server else we've to do manual transaction

bob123 is saying the storage of private keys on server is inevitable in case of automatic withdrawals. but we can use HOT and COLD wallet mechanism to store some of our funds in HOT wallets that will be used for automated withdrawals and rest of our funds will be stored in a COLD wallet that is an offline wallet and not connected to internet. This will save us from hackers to stole all of our exchange funds only HOT wallets funds can be stolen.   

[bob123]

[...] op claimed that HD wallets are not good because s/he was confused about what the concept is [...]

Where did OP say that ?

Maybe learn to read properly ? ..

If instead of trying to show-off you bother to read op's inquiry it is more than obvious that s/he is trying to handle thousands of private keys because s/he is not aware of HD wallets and the feasibility of having one master key and thousands of bitcoin addresses assigned to users, it is why s/he asks about the security of keeping track of so many private keys supposedly on a server using a database.

OP never mentioned anything about 'keeping track of private keys', but on how to store them securely.
Also.. how do you come to the conclusion that OP does not know what a HD wallet is  He never mentioned anything which could lead to that conclusion.

Even with a HD wallet, you have to handle all private keys.

Good (and big) online services do not use a wallet software like electrum etc. to handle their keys. They build their own software (which obviously have to handle private keys..).

It is really crazy, you give irrelevant information about hot wallet/cold wallet stuff to a confused newbie and s/he says thank you, then somebody tries to really help and you are attacking him because you desperately need the credit? 

Irrelevant information ?
Sure, if you want to build an exchange or any other online service which handles funds of user, knowledge about hot-/cold- wallets is useless..

You didn't help at all. All you did was saying 'yo op, use HD wallet, it is best'.

It is a shame that you even dare to comment in this thread without having knowledge regarding the important parts of safely constructing a concept for OP needs..

Of course there is always a private key corresponding to a public key, the point with HD wallets is that you don't need to store the private keys like what op thinks instead your wallet software derives the corresponding private key from the master private key. You don't need to store this master private key on the server at all because the public keys are not generated using this key but derived from a master public key which is useless for spending funds.

You still don't understand what OP really wanted to know..

So, op needs to be informed about HD wallets instead of being fooled by your irrelevant poor knowledge about hot wallets and cold wallets.

HD wallets are not the solution. That's not what he asked. He does know how HD wallet works (see his last post).. thats completely not he topic here..

Using a HD wallet won't secure automatic withdrawals and won't protect against attacks, does it ?

So, instead of posting nonsense, please educate yourself before trying to 'help' other people.

bob123 is saying the storage of private keys on server is inevitable in case of automatic withdrawals. but we can use HOT and COLD wallet mechanism to store some of our funds in HOT wallets that will be used for automated withdrawals and rest of our funds will be stored in a COLD wallet that is an offline wallet and not connected to internet. This will save us from hackers to stole all of our exchange funds only HOT wallets funds can be stolen.   

Not necessarily.

You don't need the private keys stored on the server, you just need a route between your web server and a server which does handle the payouts.

A concept without storing any private keys on the web server would be, that you have a 'withdrawal-server' which has the private keys and queries your web server to get a current list of 'next withtdrawals'.
This is the server which creates the transactions / broadcasts them.

Or - similarly - the webserver creates unsigned transactions with the public keys and sends them to the 'withdrawal-server', which then signs and broadcasts them.


All of these possibilities include that there is a way for an attack to theoretically get transactions injected into the flow. So none of these is completely sure.
But this would be a concept to avoid private keys stored on the server and therefore against them being stolen.