Hi, On Wed, 2005-11-09 at 16:46 -0800, Herman Webley wrote:
In the challenge-response they don't get in with md5($password), but rather with something like md5($challenge.$password), no?
Yes, but if the user has the md5 from the server, then he can build the $challenge.$password to submit to the server. Gordon.
On 11/9/05, Gordon Heydon <gordon@heydon.com.au> wrote:
Hi,
Not to put a spanner in the works, but I do not like the idea of being able to send an MD5 to the database. If they have compromised the database and have the original MD5, then they have a method of logging in without the password.
But then again, if they have the MD5, they can use some md5 crackers to get the original password.
Gordon.
On Wed, 2005-11-09 at 10:53 -0500, Syscrusher wrote:
On Wednesday 09 November 2005 10:29, Khalid B wrote:
Ber I agree with you that Javascript is not a solution. It gives a false sense of security and exposes the stored md5 hash of the password.
Not necessarily. Assume a password of "secret", have the browser do this:
1. Generate a random text string, let's say "x!Q37_z*P" for example, in the JavaScript in the browser.
2. The browser takes the MD5 sum of the password: "5ebe2294ecd0e0f08eab7690d2a6ee69".
3. The browser then concatenates the password MD5 and the random string, with a carriage return between: "5ebe2294ecd0e0f08eab7690d2a6ee69" . "\n" . "x!Q37_z*P".
4. The browser takes the MD5 sum of that entire string: "ec1e557633decf2c14c306af381c9011"
5. Now the browser sends to the server the cleartext version of the random string, concatenated with a carriage return and the combined MD5: "x!Q37_z*P" . "\n" . "ec1e557633decf2c14c306af381c9011"
6. At the server end, we have the MD5 of the real password in the database. Retrieve that. Concatenate it with the one-time pad (the random string, easily extracted from what the browser sent) and CR. Then, take the MD5 sum of the whole thing. It should match what the browser sent after the CR.
This nonce or one-time-pad technique is very common in authentication schemes. It won't stop a playback or man-in-the-middle attack, but it *does* keep the actual MD5 of the password from being exposed. The only cleartext sent is the nonce, and the only MD5 sent is one that included the nonce in its creation.
The technique can be further refined by having the *server* supply the nonce string as a "HIDDEN" parameter in the login form itself, ignored by a non-JS client but used by the JS encryptor. The server then can keep track of the nonce values it has recently used, and only accept those values in submitted forms. Each time one of those nonces is used, delete it from the table in the server's memory, so that each nonce can only be used once by a POST operation. This effectively stops the playback attack, because the attacker would have to get back to the server *before* the client does, else that nonce will be already invalidated. And the attacker can't play back what it hasn't seen yet.
I'm not meaning to take sides on the overall issue of whether the JavaScript authentication hash is a good idea or not -- I don't have a strong preference. But it is possible to implement it without exposing the MD5 of the actual password on the Internet.
Scott
-- Best regards, Herman Webley
!DSPAM:4372a353291217578633111!