[development] Securing Login: MD5 password hashing using javascript

[Khalid B]

My comments was on the original scheme.

I have to admit that yours is far better, but since I am no security
guru, I will leave poking holes in it to those who are more adept than
me in this.

One drawback I see is this cannot be the only authentication way,
since someone may turn off javascript in their browser. If we allow
graceful degradation, then we are back to either SSL or the existing
scheme with all its deficiencies.

On 11/9/05, Syscrusher <scott at 4th.com> 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
>
> --
> -------------------------------------------------------------------------------
> Scott Courtney     Drupal user name: "syscrusher"   http://drupal.org/user/9184
> scott at 4th dot com       Drupal projects: http://drupal.org/project/user/9184
> Sandbox:  http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
>