Earlier this summer, the team at Inversoft published a comprehensive and sophisticated guide to user data security. The guide spans from hardening servers from provisioning, up through the IP and SSH layers, and all the way to application-level techniques for password hashing, SQL injection protection, and intrusion detection. As proof that they stood behind their advice, the Inversoft team provisioned a pair of Linode hosts, a web server and database server, and gave them the hardening treatment. Inversoft offered up a fully-loaded MacBook to anyone who could break in, taunting all comers by naming the hardened web server hackthis.inversoft.com.
Needless to say, they found a way in.
[...] After discovering an unpatched, unfirewalled Elasticsearch instance using nmap, we gained shell access on a utility server used for various functions at Inversoft. On there, we found API keys for Linode left behind by a human operator. Those keys allowed us to detach disks from running servers and attach them to servers we controlled, stealing sensitive user data (all to win a prize).
(Score: 2) by Scruffy Beard 2 on Sunday August 28 2016, @04:33AM
While I have not implemented it yet, I was thinking the private key would exist only on the back-up server. If the key is lost, the data on the server is probably gone as well. Any (optional) second server would have its own private key.
Where I think encrypting your key is a little pointless is when you are backing up your keys (not the case in the scenario above). If you use a passphrase protect your secret keys, you need to store the passphrase somewhere. Encrypting the key with a passphrase also prevents m of n key distribution schemes.
And yes, the PGP or GPG file on a computer in active use should have the keys encrypted with a passphrase.
(Score: 2) by Scruffy Beard 2 on Sunday August 28 2016, @04:37AM
Maybe the confusion arose because I was using a "server" to refer to a machine with no direct network access.
Sneakernet [wikipedia.org] FTW!