> 2) Client sends hashed password, server compares against saved hash.
> Interception of hashed password results in compromise.

Yes.  It bugs the heck out of me when someone makes a "secure" protocol
in this fashion -- essentially, the hash *is* the password, and it's
being sent in the clear!


> A much better way to do security is to create a public/private key pair.
> Server sends public key to client, client encrypts password with that key,
> then sends the result to the server.  The server decrypts with the private
> key, performs a hash, then compares the result with the saved hash (this is
> to make the saved password list secure should the server become
> compromised).  If the key pair is randomly created per session, then the
> system is pretty secure (unless you have a man in the middle replacing the
> public key it it passes by - which is why eventually you need digital
> signatures, and ultimately, trusted certificates).

To make it more secure, you can add a new challenge to each query.  The
client xor's the challenge with the password before sending it, and the
server xor's the response before hashing it.

Also, if you don't mind the server having a list of the passwords, then
you go back to hashing insted of using public-key encryption: the server
can duplicate the calculation that the client does, and see if they got
it right.


Which is better?  It's not great having a password file on the disk.  On
the other hand, the man-in-the-middle attack is harder (it seems like
the server has to be up while you are doing it, wherease with the PK
scheme you can just kill the server and take its place), and it doesn't
seem as effective -- the hash you steal is only good for one session,
and it has to be used immediately.  Also, you can do stuff to protect
the server, but it's hard to do anything about making the Internet more
reliable.


Oh well.  I guess as you say, none of it is going to be real secure,
until there is a big web of digital certificates around.


-Lex