What are the best practices when setting up / interacting with a hot wallet on an application server?

Question

Let's say I have a small application running on a server that interacts with the Ethereum blockchain to occasionally send ETH to random addresses at random times. This application also has other functionality like talking to external APIs. It's not a webapp though and has no web interface. In fact, the only way of configuring / accessing the server is SSH access.

Presumably, on the server you're going to be running either geth or parity locally in order to send transactions. These transactions need to be able to be sent without any user input (entirely automated).

• What are the best practices here for working with parity or geth? Are there specific args that can be used to lock them down, yet still be able to send transactions?
• Should the local accounts be always unlocked? Should the private key encryption passphrase be stored as a file on system, environment variable, other?
• Is using cloud server providers not recommended (vs. running on your own hardware)?

Answer 1

Every situation is different, it really depends on your needs and threat model. But a few general comments:

Geth and Parity have relatively large attack surfaces and need frequent updates, so if you need high security you may prefer to run your node on a seperate server, and just sign transactions (or data to send to transactions) on the server holding the keys.

If you need to leave the server running unattended the keys will have to be unlocked, but you generally want to avoid having the decrypted keys written to disk. A common approach is to store the keys in an encrypted volume, and use a manually-entered passphrase to decrypt it into RAM, either when you start a long-running process or in a ramdisk producing a file the process can read from.

In theory a rented VM has an attack surface that your own hardware doesn't, but in practice if you need to run hardware in a datacenter for good uptime and physical security you may find it easier to make a sanely secured system with AWS or similar, as they have well-defined procedures and best practices. There is also a good case for requiring multiple signatures from multiple boxes with different models, eg one on AWS following their account security best-practices and another in your physical possession. Burgling your house and tricking AWS phone support are quite different problems, so you're safer if the attacker has to be able to handle both.

Finally, depending on what you're securing you may want to look at using a smart contract to limit what your always-on server's keys are able to do. For instance, you may want to set a maximum amount of funds that can be moved per day, and require keys to be taken out of cold storage to change it. You may also want a readily-available emergency brake, that will freeze outgoing funds until you release them with the keys from cold storage.