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: 4, Insightful) by frojack on Saturday August 27 2016, @06:22PM
More In the Box thinking on the part of the defenders, and some rule-stretching by the attackers.
Bravo!
It goes to show just how vulnerable everything is due to the intertwined nature of everything Digital. Best practices still leave vulnerabilities laying around.
The password, and its "high-tech" cryptographic offspring, is probably the single biggest security blunder the entire industry has made. The whole concept is due for some out of the left field new idea to come along and change everything. I have no clue what it will be, but it can't come soon enough.
No, you are mistaken. I've always had this sig.
(Score: 4, Insightful) by Anonymous Coward on Saturday August 27 2016, @08:37PM
I have no clue what it will be, but it can't come soon enough.
It can fuck right off if it involves fingerprints or other such nonsense.
(Score: 2) by Scruffy Beard 2 on Saturday August 27 2016, @08:58PM
Public key encryption has some feature passwords lack.
For example, I am considering encrypting my back-up in transit. Instead of sending the encryption key separately, I can simply encrypt them with the back-up server's public key.
The private key would be encrypted with a long passprase that I carry with me. The passphrase alone will not decrypt the data though.
(Score: 3, Insightful) by DrkShadow on Saturday August 27 2016, @09:06PM
Public key crypto has the same drawbacks as API keys being left around: if you have the private key, you have everything. I bet you don't even password-protect your private keys ...
(Score: 3, Touché) by gnampff on Saturday August 27 2016, @09:30PM
You lost the bet. Please consider reading the last of the three lines your were replying to. Something about a long passphrase for the key :)
(Score: 0) by Anonymous Coward on Sunday August 28 2016, @05:55AM
I see the words "would be" not the word "is."
(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!