[development] Securing Login: MD5 password hashing using javascript

[Gordon Heydon]

Hi,

On Wed, 2005-11-09 at 18:49 -0800, Herman Webley wrote:
> You can build md5(challenge)+md5(password) if you have md5(password)
> but you can't build md5(challenge+password) which is what we would
> use. So they would need to know the unhashed password, not just its
> md5.

Basically I do not want this to open up other methods for compromise the
system. You description is different to what is below, and I think may
be ok.

> Is that right?

I am not sure, but it is different from the description below.

Gordon.

> On 11/9/05, Gordon Heydon <gordon at heydon.com.au> wrote:
> > 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 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
> > >
> > > 
> > >
> >
> >
> 
> 
> --
> Best regards,
> Herman Webley
> 
> !DSPAM:4372bb124452062717165!
>