Hot wallet security

[bigselenium]

When runnning a crypto site, securing funds is obviously paramount. Now I know that most funds should be handled in a cold wallet away from any possible outside interactions. However, the funds on the hot wallet, I'm unsure about. I'd assume I'd run a wallet on a separate server with the bitcoind daemon to the web server of course, but are there any commonplace security protocols/techniques that should be employed in order to minimise risk of hot wallet funds being stolen if a breach of that second server is to occur or is there really not much I can do other than regularly move fnuds out of the hot wallet to the cold wallet?

I assume this is the right section, if not a mod can happily move it

[bob123]

This quote from DannyHamilton answering a question regarding hosted wallets (on an eventually non-secured provider) may already answer your question.
It seems to be a sweat approach.

Have a separate smaller system which is not hosted for sending funds out.  The users can place requests for funds on the hosted server where the requests can be stored.  The non-hosted server can retrieve the requests, run them through a set of sanity checks to make sure nothing unexpected is happening, and then can send out the funds in scheduled batches (reducing transaction costs).

The non-hosted server can be secured behind a firewall allowing NO incoming connections at all, and ONLY allowing the 1 outgoing connection to the hosted server.

but are there any commonplace security protocols/techniques that should be employed in order to minimise risk of hot wallet funds being stolen

To name the most obvious ones: Set up a proper firewall (only allowing connections/ports you need), make any sensitive calculations server-side, make sanity checks before withdrawals / crediting.
With those basic steps you are already better secured than roughly 50% of online services.

or is there really not much I can do other than regularly move fnuds out of the hot wallet to the cold wallet?

You should definetely move funds out of your hot wallet (or don't even receive them to you hot wallet; use an maste public key to derive public keys / addresses) regularly.
Only keep the amount in your hot wallet you need to run your business successfully. Anything above should be withdrawn to your cold storage.

[bigselenium]

This quote from DannyHamilton answering a question regarding hosted wallets (on an eventually non-secured provider) may already answer your question.
It seems to be a sweat approach.

Have a separate smaller system which is not hosted for sending funds out.  The users can place requests for funds on the hosted server where the requests can be stored.  The non-hosted server can retrieve the requests, run them through a set of sanity checks to make sure nothing unexpected is happening, and then can send out the funds in scheduled batches (reducing transaction costs).

The non-hosted server can be secured behind a firewall allowing NO incoming connections at all, and ONLY allowing the 1 outgoing connection to the hosted server.

but are there any commonplace security protocols/techniques that should be employed in order to minimise risk of hot wallet funds being stolen

To name the most obvious ones: Set up a proper firewall (only allowing connections/ports you need), make any sensitive calculations server-side, make sanity checks before withdrawals / crediting.
With those basic steps you are already better secured than roughly 50% of online services.

or is there really not much I can do other than regularly move fnuds out of the hot wallet to the cold wallet?

You should definetely move funds out of your hot wallet (or don't even receive them to you hot wallet; use an maste public key to derive public keys / addresses) regularly.
Only keep the amount in your hot wallet you need to run your business successfully. Anything above should be withdrawn to your cold storage.

That seems like a good solution to me in regards to the second server. I'm not quite sure what is meant be a "non-hosted" server however. Do you mean a server rack of my own and not a third party server or? Otherwise that seems like solid advice in ters of batching and firewalls. What sort of schedule would you suggest? Hourly? I feel the schedule would have to be frequent. The only issue I can see with the batching is that users would have to wait longer for their withdrawals instead of having them processed instantly?

As for sanity checks and important calulations, etc the practice seems similar to running non-crypto sites which is something I'm already familiar with so its nice to know those practices copy over.

I wasn't actually aware yo ucould use one public key to generate further public keys/addresses. I assume that is how most crypto sites generate their deposit addresses? Sorry if that sounds outright noobish but I'm not currently that well versed in the actual technical aspects of bitcoin hence why I'm asking the questions I am. Thanks for all the help and advice though, I really appreciate it a  lot!

[bob123]

That seems like a good solution to me in regards to the second server. I'm not quite sure what is meant be a "non-hosted" server however. Do you mean a server rack of my own and not a third party server or?

Non-hosted simply means that it is not hosted (on a 3rd party hosting service).
Like a small server at your physical place, which is only used for this one task.

What sort of schedule would you suggest? Hourly? I feel the schedule would have to be frequent. The only issue I can see with the batching is that users would have to wait longer for their withdrawals instead of having them processed instantly?

This fully depends on what kind of service you are running.
Since you can have a setup with hot-/cold wallet, you can let people withdraw at any time (and batch transactions every X minutes).
You just have to keep your hot wallet filled enough to let people withdraw, but not too filled enough to lose too much in case of an incident.

I wasn't actually aware yo ucould use one public key to generate further public keys/addresses. I assume that is how most crypto sites generate their deposit addresses? Sorry if that sounds outright noobish but I'm not currently that well versed in the actual technical aspects of bitcoin hence why I'm asking the questions I am. Thanks for all the help and advice though, I really appreciate it a  lot!

What actually is used when deriving public keys is the xpub (extended public key).
You can read about it here: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Extended_keys.

[bigselenium]

That seems like a good solution to me in regards to the second server. I'm not quite sure what is meant be a "non-hosted" server however. Do you mean a server rack of my own and not a third party server or?

Non-hosted simply means that it is not hosted (on a 3rd party hosting service).
Like a small server at your physical place, which is only used for this one task.

What sort of schedule would you suggest? Hourly? I feel the schedule would have to be frequent. The only issue I can see with the batching is that users would have to wait longer for their withdrawals instead of having them processed instantly?

This fully depends on what kind of service you are running.
Since you can have a setup with hot-/cold wallet, you can let people withdraw at any time (and batch transactions every X minutes).
You just have to keep your hot wallet filled enough to let people withdraw, but not too filled enough to lose too much in case of an incident.

I wasn't actually aware yo ucould use one public key to generate further public keys/addresses. I assume that is how most crypto sites generate their deposit addresses? Sorry if that sounds outright noobish but I'm not currently that well versed in the actual technical aspects of bitcoin hence why I'm asking the questions I am. Thanks for all the help and advice though, I really appreciate it a  lot!

What actually is used when deriving public keys is the xpub (extended public key).
You can read about it here: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Extended_keys.

Thanks again for the great reply. I really appreciate it. X minutes sounds like a far better schedule time for sure.
Will read up on the xpubs now! Thanks!