WebApp Sec mailing list archives
RE: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection)
From: "Bond Masuda" <bond.masuda () jlbond com>
Date: Wed, 17 Aug 2005 09:30:46 -0700
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
Current thread:
- Re: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection) mike (Aug 16)
- Re: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection) Noam Eppel (Aug 16)
- Re[2]: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection) Oleg Topchiy (Aug 17)
- Re: Re[2]: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection) Chuck (Aug 17)
- Re: MD5 Password encoding, "straight" vs "salted" hashes Peter Watkins (Aug 17)
- Re: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection) Thomas Chiverton (Aug 17)
- Re[2]: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection) Oleg Topchiy (Aug 17)
- <Possible follow-ups>
- RE: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection) Cyrill Osterwalder (Aug 17)
- RE: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection) Bond Masuda (Aug 17)
- Re: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection) Gary Gwin (Aug 18)
- Re: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection) Jean-Jacques Halans (Aug 22)
- Re: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection) Serban Ghita (Aug 23)
- Re: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection) Noam Eppel (Aug 16)
- Re: RE: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection) mike (Aug 17)