I don’t like the way it was written. It makes 3 separate “decent” points, but completely buries the lead. Also their solution doesn’t solve the original problem of password reuse being why you shouldn’t encrypt your keys.
No mention of how to re-encrypt an existing key with the better -o scheme; seems like a strange omission. The invocation is ssh-keygen -p -o -f keyfile if you were curious.
The named issue (known and fixed for 5 years now) does reduce the brute-force safety of the password to md5. If your password has enough entropy, you are still safe. “Worse than Plaintext” is misleading clickbait.
Sooo, You know that this is OpenSSH right? I mean someone has to write the Crypto. OpenSSH developers are among those that you might want to trust to do it right. No one is perfect though.
Actually, the code in question was written by Tatu, before openssh was forked.
Well, depending on exactly what code you mean. The key encrypting code was technically in OpenSSL (or librsa) I think. The choice to use it was Tatu’s.
This essential is the argument that you shouldn’t encrypt keys because people are probably re-using them elsewhere. Maybe they should take into account how most people use SSH in large deployments: SSH auth, LDAP integration, with sudo access being tied to the user without a password (yes it’s horrible, but that’s what most people do in my pentest experience). That means that the SSH key is the only thing that mattered in most of my tests, rarely the actual password. Plus I never go after the keys themselves, almost always the underlying ssh-agent process, why crack when I get everything in plaintext?
Side note, stop reusing passwords and just use a password manager for everything. Their postulation that no one uses a password manager with SSH keys is just wrong, I train my whole org on the importance of this.
“ in a world where I can rent a machine that tries billions of MD5 calls per second.” wouldnt the test for a successful hash operation involve using the hash to decrypt the data on each try? This would make MD5 cracking prohibitively expensive.
Would it really be prohibitive? AES is really fast, especially with hardware instructions… and you probably only have to try the first block to check for the private key’s header?
The punchline is that the AES key is just MD5(password || IV[:8]).
Would somebody please tell me if password is the phrase that you enter at the Enter passphrase (empty for no passphrase): prompt during an invocation of ssh-keygen?
Would somebody describe how the article should change to take into account empty passphrases?
I’m not sure I like this article. It raises a good point (use -o) but it’s obviously being misread.
I don’t like the way it was written. It makes 3 separate “decent” points, but completely buries the lead. Also their solution doesn’t solve the original problem of password reuse being why you shouldn’t encrypt your keys.
No mention of how to re-encrypt an existing key with the better
-oscheme; seems like a strange omission. The invocation isssh-keygen -p -o -f keyfileif you were curious.I guess the point is more about unsafe defaults than how to rekey. But nonetheless, it’s present:
Maybe an edit?
The named issue (known and fixed for 5 years now) does reduce the brute-force safety of the password to md5. If your password has enough entropy, you are still safe. “Worse than Plaintext” is misleading clickbait.
This is why you Don’t Implement Your Own Crypto! Come on folks.
Sooo, You know that this is OpenSSH right? I mean someone has to write the Crypto. OpenSSH developers are among those that you might want to trust to do it right. No one is perfect though.
Actually, the code in question was written by Tatu, before openssh was forked.
Well, depending on exactly what code you mean. The key encrypting code was technically in OpenSSL (or librsa) I think. The choice to use it was Tatu’s.
Pretty sure this comment was intended as a joke for this reason?
Yeah it kind of was. I guess it was a little obscure though.
Well, hop in a time machine back to 1996 and pick something better off the shelf…
I read the article, and the situation seems related to OpenSSL only. Joel Sing confirmed that commits https://github.com/libressl-portable/openbsd/commit/17b1f1ce28ae8bc5a873951ad6c8aa564b68c0ab and https://github.com/libressl-portable/openbsd/commit/952c1252f58f5f57227f5efaeec0169759c77d72 fixed the issues back in 2017 for LibreSSL. More details by Billy Brumley to the oss-security earlier this year: http://www.openwall.com/lists/oss-security/2018/04/16/3 .
In conclusion OpenBSD and Void Linux have this mitigated.
Those commits have nothing to do with the issue in the article.
This essential is the argument that you shouldn’t encrypt keys because people are probably re-using them elsewhere. Maybe they should take into account how most people use SSH in large deployments: SSH auth, LDAP integration, with sudo access being tied to the user without a password (yes it’s horrible, but that’s what most people do in my pentest experience). That means that the SSH key is the only thing that mattered in most of my tests, rarely the actual password. Plus I never go after the keys themselves, almost always the underlying ssh-agent process, why crack when I get everything in plaintext?
Side note, stop reusing passwords and just use a password manager for everything. Their postulation that no one uses a password manager with SSH keys is just wrong, I train my whole org on the importance of this.
“ in a world where I can rent a machine that tries billions of MD5 calls per second.” wouldnt the test for a successful hash operation involve using the hash to decrypt the data on each try? This would make MD5 cracking prohibitively expensive.
Would it really be prohibitive? AES is really fast, especially with hardware instructions… and you probably only have to try the first block to check for the private key’s header?
This is exactly what JtR does: https://github.com/magnumripper/JohnTheRipper/blob/bleeding-jumbo/src/opencl/ssh_kernel.cl#L225 Theoretically you could probably pipeline the AES into GPU processing too, which does slow the “raw” crack rate, but not all that much.
Would somebody please tell me if
passwordis the phrase that you enter at theEnter passphrase (empty for no passphrase):prompt during an invocation ofssh-keygen?Would somebody describe how the article should change to take into account empty passphrases?
That is the pass phrase entered at the prompt. If it’s empty, the key is not encrypted.