[development] Securing Login: MD5 password hashing using javascript

Herman Webley herman.webley at gmail.com
Thu Nov 10 02:49:52 UTC 2005


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.

Is that right?

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


--
Best regards,
Herman Webley


More information about the development mailing list