Why the servers stores hashed password instead of relaying on private/public key

Question

I understand why the SSL client certificates are not widely used (need to install them, problems with shared machines etc.). On the other hand when I log into the server the password is send to it and it is in server's memory. Also if the server certificate leaked and there was DNS spoofing there is little protection against getting the password by MITM. While attacks of such type are rare they still happens (see diginotar).

I came out with very simple scheme - because it is not widely used I assume that something is wrong with it:

On password set up:

1. Random salt is generated (by client, server or both)
2. The client gets salt and password and seeds the previously agreed cryptographically secure PRNG
3. The public key and salt is stored on server

On login:

1. Salt is send to client
2. Client regenerates the private key
3. The authentication relays on challenge/response between server

Is there any disadvantage of such scheme (except the additional computational/transfer overhead)?

Answer 1

If you are talking specifically about web applications (as per the tag) then even with client-side password hashing/encryption you are still just as vulnerable to man-in-the-middle as with sending a direct password.

This is because a man-in-the-middle attack can sabotage the client-side script on its way from the server to the client, to make it do something other than the desired crypto-protected passing of the password. The end user would never notice (as it would take a JavaScript debugging expert to determine that this had happened).

To defend against MitM you would have to have trusted code built into the browser (or an add-on) instead of server-sourced JavaScript. This might be, for example, HTTP Digest Authentication.

However in general if you have MitM against the application then you've pretty much lost already. Even with a secure digest-style auth scheme, you'd still be able to imitate any action the user could take in the application, nobble the password at setting/changing time, or just change the app's interface to prompt for the password in-page.

This is why the bulk of effort has been put into keeping the whole channel secure (with SSL) rather than password protection specifically. Not that SSL's perfect, obviously...

Answer 2

This scheme is reasonable. There is nothing terribly wrong with it. However, it doesn't seem to have any clear or compelling advantages over current "best practice": namely, sending a username/password over a SSL-authenticated channel, with the password stored in hashed form on the server.

It is not more secure if the server's database is leaked, because the user's public key + salt (stored in the server's database in your scheme) allows an attacker to mount dictionary attacks on the user's password in the same way that a password hash does.

It is not more secure against man-in-the-middle attacks, for the reasons @bobince explains.

It does mean that the user's password never leaves their computer, and is never stored in cleartext in the server's memory (not even temporarily). However this is probably not a large enough benefit to spur adoption, as this doesn't seem to make much difference for the kinds of attacks that are prevalent today.

In principle, your approach could be more secure against phishing, if it was supported natively by browsers, and if browsers were able to find some UI that ensures that users type their password only into the browser UI and won't be fooled into typing it into a website. In practice, though, browsers don't support this, and there's a chicken-and-egg problem with deployment (browsers aren't going to deploy something like this until many sites support it, and sites probably aren't going to deploy it on their own without browser support). Also, it is not entirely clear how to design a browser UI to prevent these spoofing and phishing attacks.

Bottom line: It is more complicated than just sending a username/password over SSL, and it doesn't provide enough benefit to warrant that development effort.