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

It depends, you can use client side hashing, but server side salt will not be possible.

have a look at the link Password encryption at client side

Answer 2

Note that keeping passwords secure against third parties parties is not all there is to it.

As soon as privacy is involved (and when ever is it not, these days?) you don't want to know the password. You can't abuse or leak what you don't have, so both you and your clients can sleep better if you never ever see their clear-text passwords.

Therefore, hashing/encrypting client-side makes sense.

Answer 3

Consider this:-

Client sends request to server "I have a password to validate".

Server sends client a one-time only random string. R$

Client embeds the user's password in this string (based on any (variable) rules you wish to apply).

Client sends the string to the server and if password OK, server logs user in.

Should server receive another login request using R$, user is logged out and the account is frozen pending investigation.

Obviously all other (normal) security precautions would be taken.

Answer 4

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 data (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.