[development] Securing Login: MD5 password hashing using javascript

[Herman Webley]

In the challenge-response they don't get in with md5($password), but
rather with something like md5($challenge.$password), no?

On 11/9/05, Gordon Heydon <gordon at 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