On 1/3/2012 2:04 PM, Lamar Owen wrote:
> 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)
This is the figure I'm using (because I actually use some chars that
aren't letters or numbers so I rounded up to 64). You got on the order
of 10^21, same as me.
> 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).
I'm not sure what their logic is for recommending 80. But 72 bits
already means that any attack is so improbable that you'd *literally*
have to be more worried about the sun going supernova.
> 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.
Actually, the top answer at that link appears to say that the server
sends the nonce to the client, and only the client can successfully
decrypt it. (Is that what you meant?)
> 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.
Yes, I've acknowledged that whether you think 1024 bits is more secure
than 72 bits depends on how literally you mean "more secure". If the
odds of an attack working in the next year are 1 in 10^10, you can
reduce the odds to 1 in 10^20, which in a strict mathematical sense may
make you more secure, but -- not really.
Furthermore, when you're dealing with probabilities that ridiculously
small, they're overwhelmed by the probability that an attack will be
found against the actual algorithm (which I think is your point about
possible weaknesses in the stream cipher).
However, *then* you have to take into account the fact that, similarly,
the odds of a given machine being compromised by a man-in-the-middle
attack combined with cryptanalysis of the stream cipher, is *also*
overwhelmed by the probability of a break-in via an exploit in the
software it's running. I mean, do you think I'm incorrect about that?
Of the compromised machines on the Internet, what proportion do you
think were hacked via MITM-and-advanced-crypto, compared to exploits in
the services?
It was that calculation I was making when I kept insisting that there
must be something more probable than brute-forcing the login or
decrypting the session -- and if I hadn't stood my ground about that,
the discussion never would have gotten around to SELinux, which, if it
works in the manner described, may actually help.
> 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.
The problem with such "basic stuff" is that in any field, if there's no
way to directly test whether something has the desired effect or not, it
can become part of accepted "common sense" even if it's ineffective.
(Consider how many doctors recommended stomach-sleeping for babies
before a more sophisticated study was done, or how many health advocates
used to recommend margarine over butter...) And once something has
become "standard", admins sometimes have a legal incentive to use it --
reinforcing its de facto status as "common sense" -- even if deep down
they realize that it's ineffective. If your server does get broken into
and a customer sues you for compromising their data, and they find that
you used passwords instead of keys for example, they can hire an
"expert" to say that was a foolish choice that put the customer's data
at risk. Even if the odds of that being the true cause of the break-in
are less than 1 in 10^10, the odds of fooling the judge are considerably
greater. (This is true of many fields, where some professionals say
they feel they have to go along with the conventional wisdom even if
they think it's wrong, because if something blows up for unrelated
reasons, they could be sued by someone who thinks the catastrophe
happened because they went against the herd.)
Case in point: in the *entire history of the Internet*, do you think
there's been a single attack that worked because squid was allowed to
listen on a non-standard port, that would have been blocked if squid had
been forced to listen on a standard port?
What's unique about security advice is that some of it can be rejected
just on logical grounds, to move the discussion on to something more
likely to help. If I hadn't argued the point about passwords vs. keys
(not to mention about prevention vs. detection), the thread would have
been over before it got to SELinux and what kinds of attacks it can
mitigate by controlling where a compromised web server can write and run
files.
> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
