Is it worth hashing passwords on the client side

Question

When I want to put a login system in place, I always compare the MD5 of the given password with its value in the users table on the server side.

However, a friend of mine told me that a "clear" password could be sniffed by a network software.

So my question is: is it a good idea to hash the password on the client side? Is it better than hashing it on the server side?

Answer 1

Basically, your friend is right. But simply hashing the password on the client side is only just better than submitting it as plain text to the server. Someone, who can listen for your plain text passwords is certainly also able to listen for hashed passwords, and use these captured hashes him/herself to authenticate against your server.

For this matter, more secure authentication protocols usually jump through a number of hoops in order to make sure, that such a replay attack cannot work, usually, by allowing the client to select a bunch of random bits, which are hashed along with the password, and also submitted in the clear to the server.

On the server:

• generate a few bits of random
• send these bits (in clear text) to the client

On the client:

• generate a few random bits
• concatenate password, the server's random bits and the client random bits
• generate hash of the above
• submit random bits(in clear text) and hash to the server

As the server knows its own random information as well as the client's random bits (it got them as clear text), it can perform essentially the same transformation. This protocol makes sure, that nobody listening in this conversation can use the information later to authenticate falsely using the information recorded (unless a very weak algorithm was used...), as long as both parties generate different "noise bits" each time, the hand shake is performed.

Edit All of this is error prone and tedious and somewhat hard to get right (read: secure). If ever possible, consider using authentication protocol implementations already written by knowledgeable people (unlike me! The above is only from memory of a book I read some time ago.) You really don't want to write this yourself usually.

Answer 2

First of all, this does NOT improve the security of your application (assuming it is a webapp).

Use SSL (Or actually TLS, which is commonly called SSL), its not really expensive (Measure the time you are using to find ways around it and multiply it with minimum wage, buying a certificate wins almost always).

The why to this is simple. TLS solves a problem (when used with bought certificates, not self signed) that is quite big in cryptography: How do I know the server I am talking to is the server I think I am talking to? TLS Certificates are a way of saying: "Me, the certificate authority, trusted by your browser, certifies that the website at [url] has this public key, with a corresponding private key, which (private key) only the server knows, look I signed my signature all over the document, if anyone altered it you can see".

Without TLS, any encryption becomes pointless, because if I sit next to you in a coffeeshop, I can make your laptop/smartphone think I am the server and MiTM (Man in The Middle) you. With TLS, your laptop/smartphone will scream "UNTRUSTED CONNECTION", because I don't have a certificate authority signed certificate that matches your site. (Encryption vs. Authentication).

Disclaimer: users tend to click right through these warnings: "Untrusted connection? What? I just want my pictures of kittens! Add Exception Click Confirm Click YAY! Kittens!"

However, if you really do not want to buy a certificate, still DO implement client side javascript hashing (and use the standford library (SJCL) for that, NEVER IMPLEMENT CRYPTO YOURSELF).

Why? Password reuse! I can steal your session cookie (which allows me to pretend to your server that I am you) without HTTPS easily (see firesheep). However if you add a javascript to your login page which, before sending, hashes your password (use SHA256, or even better, use SHA256, send them a public key you generated and then encrypt hashed the password with that, you cannot use a salt with this), and then sends the hashed/encrypted password to the server. REHASH the hash on your server with a salt and compare that to what is stored in your database (store the password like this:

(SHA256(SHA256(password)+salt)) 

(save the salt as plaintext in the database as well)). And send your password like this:

RSA_With_Public_Key(SHA256(password)) 

and check your password like this:

if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok 

Because, IF someone is sniffing your client, they will be able to login as your client (session hijacking) but they will NEVER see the plaintext password (unless they alter your javascript, however, a starbucks hacker will probably not know howto/be interested in this.) So they will gain access to your webapp, but not to their email/facebook/etc. (for which your users will likely use the same password). (The email address will either be their loginname or will be found in their profile/settings on your webapp).