[tmafbwik] Secure Remote Password

The primary benefit of Secure Remote Password (SRP) compared to SSH is to eliminate this problem:

The authenticity of host 'host.domain.com' can't be established.
RSA key fingerprint is 3c:b7:8b:1d:be:a2:11:71:e9:42:4f:9c:db:a1:12:23.
Are you sure you want to continue connecting (yes/no)?

SRP relies on knowledge of your password (a pre-shared secret) to authenticate both ends of the communication.  Kerberos works in a similar manner, except utilizing a third party.  (SSH with Kerberos GSSAPI never asks the user to verify the server public key.)

Why isn't SRP more widely deployed?  It seems a viable alternative to ad hoc key distribution and even to web certificates.  (Bootstrapping the pre-shared secret when the server and client have never met nor established an account still remains unsolved.)

According to On SRP - some implementation notes and a critical review (Bert Hubert), SRP has two potentially undesirable features.  The username goes out over the clear.  Given the username, an adversary who has compromised other services can check to see if the same username has been compromised on some other service, and try the compromised password or perhaps small variations of it.  This vastly reduces the search space for brute force password guessing, so much that even a very expensive PBKDF like Scrypt becomes ineffective.  (This weakness is irrelevant if the adversary has other means to obtain usernames, for example, the username is also used as a public email address.)

(For SSH with Kerberos, does the username go out over the clear?)

The other undesirable feature is that, given a username and compromised password (perhaps trivially guessed using the technique above), an adversary can transparently construct a man-in-the-middle (MITM).  The MITM can record a session, and if the user logs in to other hosts from this host, it can record the passwords used for them.  Perhaps the user is observed to use "su".

The key point is the adversary has complete control (root privileges, custom kernels) over the MITM, which permits keystroke logging fairly easily.  In contrast, a compromised (regular) SSH account only permits actions with that user's privileges.  Keystroke logging might still be possible, though difficult to do transparently, e.g., chsh to a hacked shell, or PATH altered to use a hacked "su".  Suspicious actions may trip root-level monitoring and logging on the machine, which the adversary cannot disable.

One possible solution to minimize potential damage is to use SRP only when the server public key is not available, e.g., the first login from the client machine.  At the first login, the server public key is obtained ( ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub ) and future logins verify it.  We put our faith in probability that the adversary hasn't already compromised the account before the first login and hasn't already constructed a MITM intercepting the first login.

The problem of what do if the server legitimately changes its public key remains unsolved, though metadata attached to the new key can help deploy an ad hoc solution.