Page 1 of 1

Confusion over the benefit of javascript md5 and server-md5

Posted: Wed Sep 28, 2005 11:02 am
by mat106
Hello,

I've been using javascript md5 (http://pajhome.org.uk/crypt/md5/index.html) in order to convert a plain text password into a hash before submitting it to a login script using POST but the following quote (found under "Protecting the password on the server at http://pajhome.org.uk/crypt/md5/auth.html) from the Javascript MD5 website has confused me over the whole benefit of using javascript in the first place.
Observant readers may notice that the value the server stores is a "password equivalent", i.e. if you knew just that then you could login. However, the protection is still worthwhile, because its main purpose is to stop an attacker using captured passwords on a different server.
I don't understand how the protection is still worthwile: Isn't it true that all a hacker would have to do is intercept the HTTP transmission, from it obtain the md5 hash of the password and then simply disable javascript and paste the md5 hash into the password field? I've tried this and it does in fact give me access!

So what's the benefit??

Posted: Wed Sep 28, 2005 12:07 pm
by Skara
Never rely on javascript to do something. Many users don't have or choose not to enable javascript. Javascript can be nice, but have it do the exact same thing serverside afterwards. If you can only do it once, do it serverside.

Posted: Wed Sep 28, 2005 12:16 pm
by dbevfat
Even though, I've also read somewhere that client-side password hashing is good, because that way the plain password is never sent anywhere. So I'm also interested in how to do that, although I agree that you should never rely on JS.

Posted: Wed Sep 28, 2005 12:30 pm
by mat106
I agree with both replies but the only way to hash the password before it's sent is by using some form of Javascript hashing.

Skara, do you know of a way to hash the password before it gets sent without using Javascript or https?

Posted: Wed Sep 28, 2005 12:35 pm
by redmonkey
If all you are doing is sending the username and password hash then it offers no benefits over sending username and plain text password, as the required variables could still be sniffed.

The (what I believe to be) standard practice is to implement a challenge/response type login which should be more secure.

Re: Confusion over the benefit of javascript md5 and server-

Posted: Wed Sep 28, 2005 1:11 pm
by Roja
mat106 wrote:I don't understand how the protection is still worthwile: Isn't it true that all a hacker would have to do is intercept the HTTP transmission, from it obtain the md5 hash of the password and then simply disable javascript and paste the md5 hash into the password field? I've tried this and it does in fact give me access!

So what's the benefit??
We've covered this about a dozen times now.

Here's the scenario it helps with. I'm evil-bob. I'm sniffing your connection. I see you login to devnet. Here, your password (sent cleartext - thanks phpbb) is "devnetpass". Your username is mat.

I then login to ebay as "mat", and try the password "ebaypass".

I get in.

With a sniffed md5sum of your password ("devnetpass"), I get this: "7c1e34fdb9582b7daa62777320ff5e81".

Tell me what your likely password on ebay is from that.. ?
redmonkey wrote:If all you are doing is sending the username and password hash then it offers no benefits over sending username and plain text password, as the required variables could still be sniffed.
Wrong. It offers superior confidentiality.

Thats the additional value. Its not transparent to attackers, so they cant use it to guess likely variants of your choice on other sites.

Take it a step further, realizing that the majority of users reuse *the same password* on multiple sites, and suddenly, there is a tremendous value in hashing.

Of course, there is even MORE value in hashing with a salt, but thats a different question and problem solver.

Posted: Wed Sep 28, 2005 4:33 pm
by Maugrim_The_Reaper
Roja raises a valid point (even I never really thought of it that way!). But most users will use the same password on other sites (though we presume sites with credit card info are NOT using the same password :()

The more secure option - assuming the client supports javascript - is to salt that same hash with a once off Challenge string from the server. Using a salt, the hash equivalent of a password is never the same one twice. In other words, salting removes even the ability for your hash to be re-used by someone sniffing your network traffic ;)

Posted: Wed Sep 28, 2005 4:40 pm
by Burrito
ohh indeed there are good things coming about this.... :D

Posted: Wed Sep 28, 2005 5:07 pm
by Maugrim_The_Reaper
Stop imagining things...;) I have a plank reserved for hint droppers...hehehe

Posted: Sun Oct 02, 2005 5:48 am
by AGISB
I don't rely on javascript. If it is so important to protect the password transmission I use SSL.

I see little additional security by hashing a password but a lot of problems that can arise if not implemented properly.

If javascript is off there is no security anyhow so it really escapes me why this should be worth all the work to put in.

If a user uses the same password on many sites the sniffer will get it anyway as almost no site uses javascript hashing so he simply gets the pass from the next site he uses.

Posted: Sun Oct 02, 2005 7:01 am
by Roja
AGISB wrote:I don't rely on javascript. If it is so important to protect the password transmission I use SSL.
If and when it is avaible, SSL is almost always superior, and should be used.
AGISB wrote:I see little additional security by hashing a password but a lot of problems that can arise if not implemented properly.
We covered the additional benefit above. Your perception that it is "little" gain is your opinion and you are welcome to it.

In webgames, the majority of sites don't have the option of running SSL, and are run without substantial modification. As such, anything the developers can do to improve the security-by-default helps hundreds of players - and many admins.
AGISB wrote:If javascript is off there is no security anyhow so it really escapes me why this should be worth all the work to put in.
See above. In most webgames, javascript is on, and SSL isnt an option. Its mostly a case of different situations and different needs.
AGISB wrote:If a user uses the same password on many sites the sniffer will get it anyway as almost no site uses javascript hashing so he simply gets the pass from the next site he uses.
Just because a user makes bad security decisions, we don't have a justification to be sloppy ourselves. Its better to improve the situation. As you said, it does add additional security. Might as well help our users and at the same time, learn better programming practices so we can use the same technology on more critical sites.

Posted: Sun Oct 02, 2005 5:41 pm
by Maugrim_The_Reaper
If a user uses the same password on many sites the sniffer will get it anyway as almost no site uses javascript hashing so he simply gets the pass from the next site he uses.
So therefore we should be sloppy also? ;) If we use hashing or C/R, then user's can't point fingers at US for their password being stolen... Just because its rarely used does not mean it has no benefit... Someone has to make a stand somewhere, you know.