Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Even though I read a lot about hashing and how passwords are protected, I am still confused about it.

  1. If passwords are hashed at client side, it will be useless because it can be sniffed and used by attacker, can't it?

  2. If passwords are hashed at server side, it will be transfered in plaintext, it can be sniffed and used by attacker, can't it?

So by my reasoning all hashing is useless. Can somebody explain how this works?

share|improve this question
@AndreyBotalov thanks but it didn't respond to my questions – Leo92 Jul 20 '12 at 10:45
There is not a useful defense against a MiTM once you are being attacked by a MiTM attack. ALL traffic is suspect, can and will be see by the man in the middle, in the original form it was sent to the server. The solution to the password problem, hash everything BEFORE it is sent to the server, this means the man in the middle only gets values that are hashed. – Ramhound Jul 20 '12 at 12:13
@Ramhound That's bad advice. It turns the hash into a password, allowing it to be used to log in. It doesn't solve anything. The only secure option is to use SSL. – Polynomial Jul 20 '12 at 12:54
up vote 4 down vote accepted

Password hashing is used to protect users in the case of a database being compromised. Transmission of the password to the server is a completely different security scenario.

Both of your assertions about traffic sniffing at the start of your question are correct. Transmitting the password in plaintext allows an attacker to sniff the password. Computing the hash on the client side essentially makes the hash the password, so an attacker can just sniff the hash and use that instead.

To answer your questions at the end:

  1. HTTPS uses SSL (or TLS) to provide endpoint-to-endpoint security. This essentially means that an attacker can't sniff out the data, since it's encrypted. He also can't inject data, since authenticity is provided too. When SSL is used, the server has a certificate that contains its public key. The certificate is signed by a CA that your browser trusts, so you can verify that it is correct. Your browser generates a session key and encrypts it using the server's public key. Only the server can decrypt it, because the only the server knows the private key. Once both the server and client know the session key, they can communicate securely.

  2. An ISP or proxy might use a man-in-the-middle attack to present you with a false certificate. If you accept that certificate, they can decrypt the conversation and inject their own data. However, you will be alerted by your browser that the certificate is invalid. Some governments get real certificates issued to them for this purpose - so you won't notice unless you inspect the certificate.

  3. If the attacker knows your WPA2 password, they can connect to the network. This allows them to sniff traffic.

In your situation, send the password over HTTPS, then hash it on the server side with a strong key derivation algorithm such as PBKDF2 or bcrypt.

share|improve this answer

As polynomial said, hashing isn't about protecting a transmitted password. It's so that if somebody gets into your database, they don't instantly have all of the passwords.

If you're concerned with a MITM attack, one thing you might want to try is using a nonce. Say you want to send password. You first send a request to the server to generate a random string. You take the returned string, and instead of sending hash(pass) you send hash(hash(pass) + nonce). Then the server compares that to the stored hash + nonce to authenticate. Even if the attacker sniffs the hash, he can't reuse it because each nonce is a one-time use.

share|improve this answer
thank you very much, that's what I was looking for and you made things looks easy to me , now I get it, but now I have question , If for each request there is a unique nonce , how is possible to crack the password like in wireless ? what the attacker should do ? – Leo92 Jul 21 '12 at 7:17
after thinking about it, the attacker can sniff the nonce and then generate rainbow table for that nonce and compare the result with the hash(hash(pass) + nonce) , right ? – Leo92 Jul 21 '12 at 7:22
You're only supposed to use the nonce once. So even if the attacker generates a rainbow table for nonce "Ab74nn", that won't help him when the next one is "vvk0I0". – Hovercouch Jul 23 '12 at 15:55
its not necessary , one nonce is enough to find the original password – Leo92 Jul 23 '12 at 18:30
I don't see how you'd be able to do that. You can't take an end hash and the nonce used and use that to get back the original password. Not without brute forcing it, which you could do without the nonce anyway. – Hovercouch Jul 23 '12 at 19:50

Password hashing is not for the security of passwords while being transmitted over the wire, but for storage on the server. We hash passwords because it sometimes happens (more often than we would like) that bad people get a peek at the server's files and/or database. For what happens on the wire, we need two things:

  • We need integrity because authentication is always relative to some subsequently exchanged data. We don't want an attacker, in position to run a MitM attack, to just wait for authentication to happen, and then hijack the live, "authenticated" connection.

  • We need confidentiality because we do not want attackers to observe passwords in transit, or even hashes of passwords, because a password hash is enough to "test passwords at home". More generally, we usually prefer that the sensitive data we are about to exchange remains confidential (that's not always the case, but it still often happens).

SSL provides both. When using SSL (called HTTPS in a Web context), the connection is protected from alterations, encrypted, and the client is reasonably sure of talking to the right server. Under these conditions, the password can be sent from client to server without any kind of hash applied to it, and that's exactly what happens in most Web sites where you type your login and password. The server must still store, somewhere in its database, some data which allows verification of the password sent by the user; that data element should be the hashed password (with the usual assortment of protections: slow hashing, salts...).

share|improve this answer

I think the missing piece for you is the use of salts. You're right in that sending a hash is no good as it can be sniffed, a salt can be used to protect the password hash. A salt is a piece of hashed random data which is added to the password hash, then the whole thing is re-hashed. spw = hash(hash(pwd) + salt) . I can send the spw plus the salt to the other side which can then use the locally stored version of the password to authenticate.

The MiTM can intercept spw and the salt, but in order to get pwd would than have to brute-force it which would be computationally expensive and time-consuming. Note that this is vulnerable to replay attacks so I'm not advocating the above as an authentication method, the point is that by adding a salt the MiTM cannot gain the password hash. Challenge Handshake Authentication Protocol is an example of a way that salts are used in authentication, but if you really want to prevent MiTM attacks use public-private keys.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.