javascript password md5 over network

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
AGISB
Forum Contributor
Posts: 422
Joined: Fri Jul 09, 2004 1:23 am

javascript password md5 over network

Post 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?
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Re: javascript password md5 over network

Post 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.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post 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...
AGISB
Forum Contributor
Posts: 422
Joined: Fri Jul 09, 2004 1:23 am

Post 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.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post 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!
Post Reply