[development] Securing Login: MD5 password hashing using javascript

[Syscrusher]

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