Disabling Password-based auth? (was RE: recent breakins)

[Tom Holroyd]

On Fri, 1 Jun 2001, Markus Friedl wrote:

> On Fri, Jun 01, 2001 at 06:59:13AM -0700, Jason Stone wrote:
> > That's exactly the point of SRP (well, one of the points) - it takes care
> > of that - even if the host in the middle has been compromised and the
> > attacker is sniffing all the ttys or something
>
> but the attack involved trojan ssh clients, so SRP does not
> help at all, whereas agent forwarded pubkey auth would have
> improved the situtations for the 'victims'.

The SRP _protocol_ can be forwarded across a trojaned ssh, and not leak
info, which is better than vanilla passwords.  Of course the current SRP
_implementation_ doesn't work that way, so you're right.  But there's
nothing wrong with SRP itself.  The problem is that the current forwarding
architecture can't deal with the SRP protocol.  If it could, then it would
be safer to use remote ssh clients with passwords.

Dykstra's problem can be solved, too.  As he mentioned, a clever trojan
could still be built -- it wouldn't get the password but it could still
insert commands into the outgoing channel that would backdoor the user's
account, or forward the established connection to an active attacker; BUT,
if the authentication used forwarded SRP, _and_ if the session keys were
switched to the new shared secret generated as a byproduct of the SRP
authentication, then the MITM would get zilch.

I agree that user education could be improved.  Right now it's easy for
users to believe that they are safe but still shoot themselves by accident
without knowing it.  Sending a cleartext password to a remote ssh is not
safe (vanilla or SRP).  There are systems out there being cracked right
now because of this.

The way that ssh clients ask for passwords could be changed.  They should
not just open /dev/tty, they should go back upstream to the originating
host, and open /dev/tty there.  It would be even better if this could be
done without the agent.

The biggest problem I see with this is that when a user on host0 sees:

host1% ssh host2
Enter user at host2's SRP password:

he or she really has no way to tell if that prompt is being issued by
host1 or by the local host0 client...  If they're running X or similar you
could pop up a window, but that's not a general solution.