I think the password message digest (hash) discussion got a little confused.
I'd like to partially support Mike in saying that hashing the password does
not really protect against sniffing/spying on the client side. Protecting the
passwords on the server side is a different topic.
[Noam Eppel wrote:]
If you are implementing a one-way hash correctly, there
should be no need to
store the plaintext passwords. All that should be stored is
the resulting
hash of each password.
Yes, the benefit of the server side password message digests is exactly to
avoid storing them in plaintext. However, the plaintext password has to be
supplied by the client because it is needed to verify a stored hash together
with additional salt. This is independent of the password handling on the
client.
I believe Mike wanted to say that hashing the password on the client side
before entering it into a browser field does not significantly increase
security. I'd agree with that and it does not contradict what you are saying
about compromising the passwords on the server side.
On the client side it would be possible to use a hashed version of the
password (the new plaintext password actually). I don't see why this would
significantly increase protection against sniffing/spying on the client side.
The resulting plaintext hash is actually just another representation of the
plaintext password and can be stolen and replayed the same way. For the
server, this is just the plaintext password.
I assume the following:
If there is any browser field input that is verified on the server side as a
multi-time access string it is vulnerable to sniffing/spying on the client
side to a certain extent. Just providing a different representation does not
increase security. The only way to increase security is to use a *protocol*
instead of a single access string or an access string with limited validity
(e.g. OTPs, challenge-response protocols, etc.).
Cyrill
