Just jumping on this thread as a newbie...
The replay of the hash of passwd vs. the replay of plaintxt passwd point is
valid. However, I guess when I read "implementing a one-way hash correctly"
it implies to me more than just taking a simple hash of passwd. When I read
that sentence (and this could totally NOT be what Noam Eppel meant to say),
the following is the type of implementation that comes to mind:
1) server generates one-time use random salt K, let H(P) be hash of passwd,
H() being hash function
2) server generates H(H(P),K) and stores it as valid for X minutes
3) server sends K to client
4) client receives user passwd P from user input, generates H(P) and then
generates H(H(P),K)
5) client sends H(H(P),K) back to server within X minutes to authenticate
In this sense, because K will cause the H(H(P),K) to be different, a replay
of H(H(P),K) attack is not possible if the K was already used once to
authenticate (once authentication is successful, server side marks H(H(P),K)
as used and cannot be used again) and would also have to be performed within
X minutes. Even though you can potentially sniff K, you have to know P in
order to generate H(P) and then generate H(H(P),K) and do this before the
"real" user authenticates, otherwise H(H(P),K) is marked invalid and you
have to wait for the next generated K.
I'm no crypto expert here, so there might still be an attack against this
approach, but I would think something like this "properly" implemented by
someone who knows auth protocols would make client-side hashing a valid
security mechanism.
My point being: yes, simple hash of passwd isn't good enough, but there is a
way to use client-side hashing that can increase the security of the
authentication protocol.
-Bond Masuda
Security Consultant, CISSP
-----Original Message-----
From: Cyrill Osterwalder [mailto:cyrill.osterwalder@seclutions.com]
Sent: Wednesday, August 17, 2005 12:47 AM
To: Noam Eppel; mike@sharecube.com; webappsec@securityfocus.com
Subject: RE: MD5 Password encoding (was: Defeating Citi-Bank Virtual
Keyboard Protection)
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
