[development] Securing Login: MD5 password hashing using javascript

[Gordon Heydon]

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
> 
> !DSPAM:4372a353291217578633111!
>