OpenSSH daemon security bug?

[Jamie Beverly]

----- Original Message ----

> From: Michael Stone <mstone at mathom.us>
> So you're commonly seeing network-based brute-force (not dictionary) attacks 
> against passwords via SSH? That's the brute-force risk that you're mitigating by 
> going to private keys. In my experience the password compromises via SSH are for 
> passwords like "admin" and "password"--which you can mitigate perfectly well 
> without going to key based auth. If you're really curious about this you can gin 
> up a ssh that logs incoming passwords and see what people are actually trying.

Yes, in fact brute-force ssh-scans do occur quite frequently. Granted, they are not as frequent as dictionary scans. However, because even "strong" passwords/phrases typically contain less than 40 bits of entropy, the time it takes to brute-force even "strong" passwords/phrases is finite, and even comparatively brief. 

> (The other major vector is password capture at a compromised endpoint, but keys 
> in themselves aren't going to help you there.) 

Actually, keys themselves are going to help you there; because public key authentication relies on the use of a randomly generated challenge response; an intruder cannot steal your private key from an end-point you are connecting to. They can only determine that you have that private key. They could easily harvest passwords, as the passwords themselves, or a hash of them (as with some SASL mechanisms), must be transmitted to the host with password authentication. 

A password is the authentication token itself, A private key is used to demonstrate the ability to decipher a challenge, and that correctly-deciphered challenge is the authentication token, which is used only once.

> I don't think anyone can argue 
> that there aren't issues with SSH passwords being attacked these days, but those 
> are pretty much always "stupid password" issues rather than "password" issues. 

True. 

> One way to mitigate that is to make a bunch of configuration changes to disallow 
> passwords.  Another way to mitigate that is to make a bunch of configuration 
> changes to disallow stupid passwords. In general the problem tends to be that 
> someone didn't configure things up front to disallow stupid passwords and then 
> blamed the technology rather than the configuration.

Except that passwords as a form of authentication are themselves fundamentally weak. Humans are simply not generally capable of remembering strings containing hundreds of bits of entropy. Even strong passwords take only days to weeks to brute-force verses the years to decades it would take to brute-force a private key. 

> > As dkg points out, you have to trust your users not to do stupid things, and 
> more often than not, continue to find yourself disappointed when they do in 
> fact, do stupid things. That said, there is NO case where password 
> authentication is MORE, or even nearly AS secure as private key authentication. 
> Public key authentication mitigates more risk.Period. 
> 
> Spoken as someone who hasn't seen massive network compromises caused by poorly 
> managed SSH keys?


Spoken as someone who has seen several massive network compromises caused by cracked "strong" passwords, containing >= 10 characters, 2 special, 3 upper, and 3 lower, required to be changed every 30 days, and no sooner than 10 days after having been changed, and not allowed to be duplicated for at least 10 iterations...  But you're right, I have not seen a massive network compromise caused by poorly managed SSH keys, though I don't discount that it certainly could happen.

> Public keys mitigate *different* risks and have *different* 
> vulnerabilities. 

Essentially true, public keys mitigate the most common attack methods used for authentication based intrusions: brute-force/dictionary based attacks, and end-point/in-transit token interception/theft. Passwords do not. Both require the the individual to prove they have a valid authentication token. 

> Making any kind of general pronouncement is dangerously 
> oversimplifying things.

Here is a general pronouncement that is not oversimplifying things: 
   Passwords:
       Have no password protecting them from theft.
      Strong passwords contain around 36-100 bits of entropy
      Are crackable via brute-force within days to weeks
      Even "strong" passwords are likely crackable more rapidly via 'hybrid' dictionary attacks.
      Must be sent to a remote end-point to authenticate, and so could easily be stolen.
      Can be sent via email, or stored in clear-text in files, etc.
      

    Private keys:
       May or may not have a password protecting them from theft.
       The worst possible private key contains 768 bits of entropy
       Crackable via brute-force only, and that would in theory take years to decades.
       Are never sent to a remote end-point for authentication. 
       Can be sent via email, or stored in clear-text in files, etc. 


The apples-to-apples comparison clearly demonstrates that public key authentication imparts less risk (at least until somebody comes up with a good P=NP proof...). And also clearly demonstrates that people can still do stupid things with them, because people can do stupid things with anything, even biometrics. 


> Put a different way: given your particular threat profile, is a 2048 bit key 
> less secure than a 4096 bit key? Would a 8192 bit key add a lot to your 
> security? Sometimes security has nothing to do with the math and a lot more to 
> do with the implementation and the human factors.


A 2048 bit key is less secure than a 4096 bit key, but as both would take years to crack (the latter taking far longer) the difference in practical security is less relevant. 
Security is always about math: Two fields of math in particular: probability, and accounting; aka How likely is this threat, and how much $$$ would it cost us if exploited. The human factors lend only to probability, and are most easily addressed by education, and making insecure practices less convenient.

 
> Mike Stone