Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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
1  
@Leo92 - I have simplified the question down to your core one. I think you will find the others have already been answered on Security SE. –  Rory Alsop Jul 20 '12 at 17:42
add comment

4 Answers

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
add comment

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
show 2 more comments

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
add comment

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
    
MiTM simply intercepts what is sent to the server in plaintext. Unless the password is hashed before it is sent to the server of course. –  Ramhound Jul 20 '12 at 12:11
    
Exactly, which is why salts work. The method assumes that the entire communication between client and server can be intercepted. –  GdD Jul 20 '12 at 12:16
2  
No, it's not computationally expensive and time consuming. I don't even need to crack your hash, because the hash + salt becomes the password when you use such a scheme. I can just sniff that salt and hash, and I get logged in when I sent them to your server, without ever needing to crack anything. –  Polynomial Jul 20 '12 at 12:19
    
You are entirely correct if I was suggesting that method as a way to authenticate, however what I was doing was explaining how salts can be used to protect password hashes in transmission as I think that's going to help answer the original question. The point is that if you send the hash without some sort of protection then it is definitely going to be sniffed and easily used in a MiTM attack, but that there are ways to defeat that. –  GdD Jul 20 '12 at 12:30
    
It's bad full stop. What if the database is compromised? Then the attacker just has to take those hashes and send them to your login script. No cracking required. –  Polynomial Jul 20 '12 at 12:51
show 8 more comments

Your Answer

 
discard

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.