In a network connection over an insecure channel I do the following:

  1. Server sends database salt and a nonce to the client;
  2. Client computes and sends hash(hash(pwd + salt) + nonce);
  3. Server computes hash(db_pwd_hash + nonce) and compares it to the hash from the client.

While it does not expose the password to a passive listener and is not vulnerable to replay attacks, a man-in-the-middle attack supposedly is an issue. Why exactly?

I consider a vulnerability to be the ability to obtain the password or its non-salted hash. I do not care about the security of the following session.

  • 2
    you are exposing the salt, which allows for pre-computing a rainbow table in order to discover a password or a collision
    – schroeder
    Commented Dec 16, 2017 at 21:17

1 Answer 1


Active eavesdropper MIM:: With a MIM able to not only see, but also modify information exchanged between you and the server (eg: a proxy), I can intercept the first message and change the salt and nonce to zero values.

You will reply with a hash of your password with basically no extra data added to it. I can take this hash and look it up in a pre-computed table (lookup table or rainbow table) to see if I can find your password matching the hash.

Passive eavesdropper MIM:: Now, let's say I'm an observer only and cannot modify any data within your communication but still see it all. Since I know your salt and nonce, I can attempt brute force or dictionary attacks on your password. This is probably more expensive but would still work in case your password is weak.

This should show you how important it is to exchange authentication information over a secure channel. The minimum requirement should be TLS with server certificate verification.

edit: server certificate verification includes certificate chain verification and server hostname verification (the host you're connecting to is the one listed in the server certificate). The latter is important to prevent MIM attacks.

  • Great answer! Another option for the active MITM, if this is a webpage, is to modify the JS to just send the password in plaintext to the attacker.
    – Anders
    Commented Dec 16, 2017 at 22:04
  • I was ignoring client modification and focusing on authentication communication only, but you are definitely correct. If the client application is served by the server (web-based apps), then you have a MIM problem with content as well. As you mentioned, the attack is even cheaper there. Again, the answer there is to make sure the content (html/js/....) is served over a secure channel.
    – Marc
    Commented Dec 16, 2017 at 22:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .