openssh unix dev - Jun 2001 - Disabling Password-based auth? (was RE: recent breakins)

Crap.  I hit send too fast.  Last sentence in
first paragraph should have read "no completely
secure way" for authentication to be passed--
because the agent-based forwarding program
could have been compromised as well--except for
the cases already mentioned such as SRP and
RSAAuth where the auth. information is better
protected. 

Even if the SF server had been capable of forwarding
the password auth. the Apache compromise could
still have happened--password authentication really
isn't secure enough for most cases.
Bottom line is that too many people use password-based
authentication, but some of them *do* need it.
More people *should* be moving to RSAAuth or
SRP, but both methods require user training.
Forcing that by disabling a long-standing feature
is not the best to proceed IMHO.  Getting people
to think about what they're doing is better--but
raising user awareness is one of those things that
security always seems to depend upon...
> -----Original Message-----
> From: Loomis, Rip 
> Sent: Friday, June 01, 2001 9:46 AM
> To: openssh-unix-dev at mindrot.org
> Subject: Disabling Password-based auth? (was RE: recent breakins)
> 
> 
> All--
> 
> But it's not as simple as forwarding the password-based
> authentication.  Regardless of what method was used to
> SSH from system one (user's) to system two (SF), the
> user then started up *a second* SSH session to go
> from two (SF) to three (Apache).  There is no effective
> way for any authentication information from the first
> session to be passed to the second, in my mind.
> 
> Remember that the SF servers had suffered a root
> compromise--so any non-password-based authentication
> that would allow the user on the SF system to get to
> the Apache systems could have been equally compromised.
> 
> The correct fix is *not* to disable password-based
> authentication, but to ensure that users understand
> that SSH is not a silver bullet.  An SSH session should
> generally only be initiated from a more secure system
> to a less secure system--in my case, the system on my
> desk is one that I have personally hardened and that
> is closely monitored, so I have no problem using SSH
> to go out to my ISP and read mail.  I would think
> *very* carefully before using SSH in reverse, since my
> ISP's systems are (IMHO) much less secure.
> 
> I'm as appalled by what happened to SF and Apache as
> anyone else, but I would ask that we work on the
> user awareness issue, which I believe is the real
> "root" problem (pardon the pun).  For the cases
> where someone needs to get from system A to system B
> with some basic level of security and doesn't have any
> other credentials/authentication available, there really
> is no substitute for password-based authentication.
> 
> --
> Rip Loomis
> Brainbench MVP for Internet Security
> http://www.brainbench.com (Transcript 1923411)
> 
> 
> > -----Original Message-----
> > From: Tom Holroyd [mailto:tomh at po.crl.go.jp]
> > Sent: Friday, June 01, 2001 4:53 AM
> > To: openssh-unix-dev at mindrot.org
> > Subject: Re: recent breakins
> > 
> > 
> > On Fri, 1 Jun 2001, Gert Doering wrote:
> > 
> > > On Fri, Jun 01, 2001 at 11:24:49AM +0900, Tom Holroyd wrote:
> > > > But what about multiple links?  It should be possible to
forward
> > > > authentication requests back to the user's keyboard. 
The
> > SRP protocol can
> > > > be forwarded over any number of links, *even through a 
> > trojaned ssh*
> > > > without revealing any information that a cracker can use.
> > >
> > > Same with agent forwarding and using RSAAuthentication.
> > 
> > True.  Too bad the guy wasn't using it.  Why wasn't he using
it?
> > 
> > Perhaps OpenSSH should simply disallow password authentication?
> > 
> > This type of man-in-the-middle attack (trojaned ssh) is not 
> > theoretical
> > anymore, and password authentication is broken.
> > 
> > 
> > The question is, can password authentication be (securely) 
> > forwarded?  If
> > not, then we really should remove password authentication as 
> > an option.
> > 
>