How password hashing is useful in MITM attack?

Question

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

If passwords are hashed at client side, it will be useless because it can be sniffed and used by attacker, can't it?
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?

See http://security.stackexchange.com/questions/7057/i-just-send-username-and-password-over-https-is-this-ok — Andrei Botalov, Jul 20 '12 at 10:39
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

score 5 · Accepted Answer · answered Jul 20 '12 at 10:46

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:

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

score 3 · Answer 2 · answered Jul 20 '12 at 20:07

3

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.

answered Jul 20 '12 at 20:07

Hovercouch

323
1
7

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 07: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 07: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
simply after sniffing the nonce , you should generate a table in this way: hash(hash(wordl) + nonce) ; hash(hash(word2) + nonce) after that you can just match the end hash , if you find it you find the password , of course i am not saying that its a good way but its possible to do – Leo92 Jul 23 '12 at 20:59
Two things. First, in that case you might as well brute force it. If your third try gets you the right password then you have no reason to check the next 999,999,999,999,999,997 possibilities. Second, you have the same issue with any hashed password. All the nonce does is prevent an attacker from sniffing the end hash and replaying that to the server to convince it he has the 'right' password. The nonce doesn't protect you from the attacker getting your password, besides for increasing the entropy a bit. And if he figures out the nonce, not even that. – Hovercouch Jul 23 '12 at 21:16

score 0 · Answer 3 · edited Oct 07 '21 at 06:47

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...).

GdD · Answer 4 · 2012-07-24T09:02:39.393

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.

How password hashing is useful in MITM attack?

4 Answers4