On Tuesday, January 03, 2012 03:24:34 PM Bennett Haselton wrote:
> That there are 10^21 possible random 12-character alphanumeric passwords
> -- making it secure against brute-forcing -- is a fact, not an opinion.
> To date, *nobody* on this thread has ever responded when I said that
> there are 10^21 possible such passwords and as such I don't think that
> the password can be brute-forced in that way.
Hmm, methinks you need to rethink the number. The number of truly random passwords available from a character set with N charaters and of a length L is N^L. (see https://en.wikipedia.org/wiki/Password_strength#Random_passwords )
If L=12, then:
For:
The numerals only: 10^12.
The Uppercase alphabet only: 26^12 (9.5x10^16)
Uppers and lowers: 52^12 (3.9x10^20)
Numerals plus uppers and lowers: 62^12 (3.2x10^21)
Base64: 64^12 (4.7x10^21)
Full ASCII printables, minus space: 94^12 (4.76x10^23)
This of course includes repeating characters. NIST recommends 80-bit entropy-equivalent passwords for secure systems; 12 characters chosen at random from the full 95 ASCII printable characters doesn't quite make that (at a calculated 78 bits or so).
Having said all of that, please see and read http://security.stackexchange.com/questions/3887/is-using-a-public-key-for-logging-in-to-ssh-any-better-than-saving-a-password
The critical thing to remember is that in key auth the authenticating key never leaves the client system, rather an encrypted 'nonce' is sent (the nonce is encrypted by the authenticating key), which only the server, possessing the matching key to the authenticating key, can successfully decrypt. This effectively gives full bit-strength for the whole key; 1024 bits of entropy, if you will, for 1024 bit keys. This would appear to require a 157 character random password chosen from all 95 ASCII printable characters to match, in terms of bit entropy. Obviously, the authenticating key's protection is paramount, and the passphrase is but one part of that. But that key never travels over the wire.
In stark constrast, in password auth the password has to leave the system and traverse the connection, even if it's over an encrypted channel (it's hashed on the server end and compared to the server's stored hash, plus salt (always did like a little salt with my hash....!), not the client, right? After all, the client may not possess the algorithm used to generate the hash, but password auth still works.). This leaves a password vulnerable to a 'man in the middle' attack if a weakness is found in the negotiated stream cipher used in the channel.
Even with a full man-in-the-middle 'sniff' going on, the key pair authentication is as strong as the crypto used to generate the key pairs, which can be quite a bit stronger than the stream cipher. (56 bit DES, for instance, can be directly brute-forced in 'reasonable' amounts of time now). Pfft, if I understand the theory correctly (and I always reserve the right to be wrong!), you could, in theory, securely authenticate with keys over a nonencrypted session with a long enough nonce plaintext and the nonce's ciphertext traversing the wire in the clear. Of course, you encrypt the actual session for other reasons (primarily to prevent connection hijacking, since that defeats the Authorization and Accountability portions of triple-A), but the session encryption and the key auth are two distinct processes.
I've been reading this thread with some amusement; while brute-forcing is an interesting problem it is far from the most important such problem, and simple measures, like not allowing random programs to listen on just any port (or for that matter make random outbound connections to just any port!) is just basic stuff. Machines are hacked into almost routinely these days without any initial knowledge of the authentication method or credentials, but by security vulnerabilities in the system as set up by the admin. SELinux and iptables are two of the most useful technologies for helping combat this problem, but they (and any other tools to improve security) must be properly configured to do any good at all.
And there are many many more Best Practices which have been (and continue to be) refined by many years of experience out in the field. Reality is reality, whether the individual admin likes it or not, sorry.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
