Page 1 of 1

javascript password md5 over network

Posted: Thu Feb 23, 2006 12:47 am
by AGISB
I just had a thought and want to check it with you guys.


We had the discussion about using javascript to md5 a password to make it more secure. I never felt that it is a good idea to base any security means on a technology that can be disabled.

Now here is my new thought. As I want to protect against someone sniffing the network that person would only get a [a-f0-9]{32} string. If he just turns of javascript and places that string into the password field the password goes over the network as if it were md5'd. If the length of the pw field is restricted he can make his own login form or fakes the post request.

That would defeat the whole purpose of using a md5 hash. Am I right here or do I overlokk something?

Re: javascript password md5 over network

Posted: Thu Feb 23, 2006 6:32 am
by Roja
AGISB wrote:We had the discussion about using javascript to md5 a password to make it more secure. I never felt that it is a good idea to base any security means on a technology that can be disabled.
We aren't basing the security on a technology that can be disabled.

We are offering users (by default) a method to prevent their password from being sent clear-text over the network. If they choose to disable that method (javascript), that is their choice.
AGISB wrote:Now here is my new thought. As I want to protect against someone sniffing the network that person would only get a [a-f0-9]{32} string. If he just turns of javascript and places that string into the password field the password goes over the network as if it were md5'd. If the length of the pw field is restricted he can make his own login form or fakes the post request.

That would defeat the whole purpose of using a md5 hash. Am I right here or do I overlokk something?
You overlooked using a one-time pad as the salt.

The server should send a form with a hidden field that is the one-time pad (call it a shared secret). Then the client takes that one-time pad, and combines it with the password entered in the field to generate the md5.

That way, even if the attacker sniffs the md5, he can't re-enter it - because the one-time pad has already been used, and now its not valid any longer.

Posted: Thu Feb 23, 2006 7:38 am
by Maugrim_The_Reaper
I never felt that it is a good idea to base any security means on a technology that can be disabled.
Defense in Depth would suggest the opposite.

Javascript is a common client side language enabled by the vast majority of users. If I followed your thinking I would remove an effective protection scheme that works for about 97% of all users, just because its incapable of protecting the other 3% who've chosen to disable javascript.

How could that possibly make sense? We're talking about an automatically active password protection scheme which has no discernable impact on the useability (it falls back gracefully in the absence of javascript). Its a no brainer.
Now here is my new thought. As I want to protect against someone sniffing the network that person would only get a [a-f0-9]{32} string. If he just turns of javascript and places that string into the password field the password goes over the network as if it were md5'd. If the length of the pw field is restricted he can make his own login form or fakes the post request.
I suggest reading my tutorial on a Challenge/Response login system or reading up on theory about the use of one-time salts. As Roja has already stated that's not possible. The salt is random, and may only be used once (it is then deleted from the database). An intercepted response hash with a salt is therefore worthless - its unuseable. Intercepting an incoming challenge hash is likewise useless (it's a salt not salt+passwd). Essentially a network sniffer can sit there and sulk all day and get nowhere.

It's not an absolutely perfect system however, but in the absence of SSL its far superior to an approach without it...

Posted: Thu Feb 23, 2006 1:06 pm
by AGISB
The token of course defeats my thought. I just saw an implementation without it and the tought appeared to me. Should have reread the tutorial before posting. At least I found a flaw in the logic of the application I checked.

Posted: Thu Feb 23, 2006 4:02 pm
by Roja
AGISB wrote:The token of course defeats my thought. I just saw an implementation without it and the tought appeared to me. Should have reread the tutorial before posting. At least I found a flaw in the logic of the application I checked.
Hey, thats a HUGE improvement over most developers. Congratulations on critical thinking!