views:

53

answers:

2

Hi everybody,

When I want to put in place a login system, 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 on the server side?

Thank you,

Regards.

+1  A: 

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.

Dirk
How can he authenticate with the hashed password in the login system since it will be hashed again?
Zakaria
If you store your passwords in hashed form on the server (as you should) then the client will have to hash the password twice: first, the password alone, so it matches with the server's view of the world, and then as described above for the protocol's sake.
Dirk
A: 

You're likely ok not to worry about this - as Dirk mentions even if you hash the passwords, a malicious user could be on a network and see the hash get sent, and could simply send the same hash himself.

It is slightly better, in that it prevents the malicious user from knowing what the password is, but since he can still log in, that's likely not that helpful.

In general, if you're concerned enough about user's safety that you want to prevent people from sniffing passwords over the network, you'll want to use a secure SSL server. If this isn't a big enough concern for you (if you're not a bank, major retailer, or otherwise a bigshot website, it's probably not) you'll be alright just leaving it alone.

dimo414