A "hot wallet" (i.e. one running on a server connected to the internet) is always going to be problematic.
Depending upon your needs you'd be better of having coins put into "cold storage" and signing transactions *offline* although that may not be suitable due to delays (especially if you process the *offline* transactions manually).
Typically sites like exchanges use a combination of "hot" and "cold" wallets to provide for quick response but with added security (better to only lose say 10% of the BTC due to a hacker than 100%).
Topic: Securing wallet for e-commerce use (Read 422 times)
Suppose I want to run a service on a webserver that not only receives but also sends out BTC, like a gambling or an exchange site.
Now suppose I do not trust any external service for sending out transactions, because e.g. recent events make me feel strongly against relying on third parties.
How would I go about running by bitcoind securely on my own server(s) without fear of being compromised? All I can think of is separating bitcoind from the webserver and run all transaction orders via a locked down gateway, probably with some kind of queue system, but this just makes attack surface smaller and does not really solve the problem. Something like webserver <--> order DB <--> bitcoind, with the order db only listening to the one port it needs and requiring encryption + authentication. But I'm not really satisfied with this design.
What are the best practices for this?
Now suppose I do not trust any external service for sending out transactions, because e.g. recent events make me feel strongly against relying on third parties.
How would I go about running by bitcoind securely on my own server(s) without fear of being compromised? All I can think of is separating bitcoind from the webserver and run all transaction orders via a locked down gateway, probably with some kind of queue system, but this just makes attack surface smaller and does not really solve the problem. Something like webserver <--> order DB <--> bitcoind, with the order db only listening to the one port it needs and requiring encryption + authentication. But I'm not really satisfied with this design.
What are the best practices for this?
Jump to: