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?
javascript password md5 over network
Moderator: General Moderators
Re: javascript password md5 over network
We aren't basing the security on a technology that can be disabled.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 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.
You overlooked using a one-time pad as the salt.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?
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.
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
Defense in Depth would suggest the opposite.I never felt that it is a good idea to base any security means on a technology that can be disabled.
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.
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.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.
It's not an absolutely perfect system however, but in the absence of SSL its far superior to an approach without it...
Hey, thats a HUGE improvement over most developers. Congratulations on critical thinking!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.