[development] Securing Login: MD5 password hashing using javascript

[Darrel O'Pry]

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


Sounds like a JS/html chap implementation...