Argument Against MD5 Authentication

by David Norman

Every now and then I read some talk about a website using JavaScript to MD5 hash user passwords for login.

The idea is to protect the password against passive eavesdropping.  There are several problems with the assumption of security with MD5 password POSTs, however.

Man-in-the-Middle Attack

Nobody could implement a JavaScript method of authentication without considering users who have JavaScript turned off.

If an attacker can read the password, hashed or not, they can also likely make malicious changes to the JavaScript code (or leave it out to pretend JavaScript is turned off).  The attacker just needs to act as a proxy between the client and the server, and substitute the login JavaScript code with something to send the password in the clear.

For most software, exploits and intrusions are not a matter of if, but when.

The average LAMP installation of a CMS stores hashes of passwords in MD5 format.  When the software is exploited to expose the user password hashes, accepting hashed passwords for login then is the password, without a "man-in-the-middle" attack.

Improved Authentication

To improve on simply sending the password in hashed format, there are two popular additions to the authentication process.

One is to add a CHAP-style challenge for the user to validate.  In this method, the server sends a challenge value with the login form.  When the user submits the form, the JavaScript clears the password field and sends back MD5 (username:password:challenge), or some variation, as a "challenge" variable in the POST information.

If the server receives information in the "password" POST variable, it knows the client doesn't support JavaScript and accepts the plaintext password.  This method complicates a "man-in-the-middle" attack, but a determined attacker can sniff out the challenge information, too, or simply break the JavaScript enough so it doesn't reset the password field.

The second is to limit authentication to a single IP address per session.  Even if this was successful in preventing an attacker from session hijacking, it still doesn't solve the original "man-in-the-middle" attack to replace JavaScript with malicious code.

Moreover, it just makes headaches for users behind round-robin NAT firewalls.  A variation of this authentication method is to lock the user session to the user's browser signature.  Any long-time Mozilla user knows how easy it is to forge a browser signature.

Dumb Users

Users that use the same password for their favorite bulletin board website as their PayPal account have more security problems than the bulletin board site should worry about protecting.

If you use your secure password over an unencrypted channel, you get what you deserve.  JavaScript interpreters are not designed for secure programming anyway, so who knows what they leave sitting around in memory.

If you're considering building JavaScript MD5 authentication into your open-source project, also consider some novice administrator might then not implement SSL because they think JavaScript MD5 hashing is equivalent.  It's not.

If you're genuinely concerned about protecting your users' passwords, then consider whether you want their communications with your server sniffed or not, which can't be solved with MD5.  SSL, or SSH tunneling if you like complexity, is the only reliable way I see to protect from sniffers.