OpenSSH daemon security bug?

Jamie Beverly jamie.beverly at yahoo.com
Wed Jan 6 09:36:28 EST 2010


Full View
Re: OpenSSH daemon security bug?...
From: Jamie Beverly <jamie.beverly at yahoo.com>...Add to Contacts 
To: Michael Stone <mstone at mathom.us>  
________________________________

 ----- Original Message ----

> From: Michael Stone <mstone at mathom.us>
> To: openssh-unix-dev at mindrot.org
> Sent: Tue, January 5, 2010 11:18:03 AM
> Subject: Re: OpenSSH daemon security bug?
> 
> On Tue, Jan 05, 2010 at 07:27:00PM +0100, you wrote:
> > Password authentication with a weak password is in itself no more secure
> > than public key authentication where the private key is protected with a
> > weak password. In the former case the attacker only needs to guess the
> > password, in the latter case they also need to get the private key.
> > Knowledge of the public key does not help an attacker.
> 
> You can force the password complexity on the server side. You can't force the 
> key management through technical means. That's a very important difference. 
> Where this has proven to be a major headache in practice is when people have 
> copies of their private keys scattered around on various machines, leading to 
> intruders being able to jump from one machine to another. (Possibly from one 
> organization to another, especially in collaborative environments like .edu's.) 
> Private keys are seldom expired on a routine basis, so there may be forgotten 
> copies lying about that haven't been used in years. (Should people do this? No.  
> Does it happen? Yes. Can you prove none of your users have done it?  Probably 
> not.) Even with a strong password, there's a big difference between a passive 
> offline attack against a key and an active brute force of a login password.


This
could easily be handled via a PAM module; one that tracks user's public
keys, and forces them to change every N (configurable) days... with
similar rules to password management, i.e. no repeats within N days,
cannot change for N days, etc,etc...

I suspect it would have to
sit in the session stack so that it would still be hit in the
pam_open_session phase of login via public-key authentication... 

If there is interest, I'd be happy to write it. 


> Mike Stone
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


      


More information about the openssh-unix-dev mailing list