At my Company, we put a honeypot in our network and it raised us the Lansweeper SSH password used to connect to the scanned assets (and it is reusable over many boxes...).
So it is a way for an attacker to get sensitive passwords in a corporate network.

I was like "Does SSH not use challenge-response?". Then I thought a little and said "I guess if you use challenge-response, then the hash is the secret, so if it is compromised, the attacker can perform pass-the-hash".

I read a little bit on the Wikipedia article about challenge response and found this:

"Since the password itself is not stored, a challenge-response algorithm will usually have to use the hash of the password as the secret instead of the password itself. In this case, an intruder can use the actual hash, rather than the password, which makes the stored hashes just as sensitive as the actual passwords. SCRAM is a challenge-response algorithm that avoids this problem".

I read about SCRAM on Wikipedia and I don't see any reason why it could avoid pass the hash. The server sends the salt and the number of iterations of bcrypt and the client must reconstruct the good hash. The server stores that hash.

So if someone compromises the server, he can reuse the hash as a password (pass-the-hash).
The one who added this sentence about SCRAM pretends that "plaintext-equivalents can be avoided with simple C/R schemes" in the Wikipedia discussion. He takes his article as a reference: https://openwall.info/wiki/people/solar/algorithms/challenge-response-authentication.

In this article, he talks about an alternative where the server stores a hash of the hash. So, okay, if you compromise the server you cannot reuse hash, but what the client sends is the direct entry of that hash, so it is not anymore a challenge-response approach.

EDIT with answer: My point was:

  1. if the server stores H(pass) and the client sends H(nonce,H(pass)) then H(pass) is as sensitive as the original password
  2. If the client sends H(nonce,pass) the server needs to store the plaintext pass to compute H(nonce,pass) on its side
  3. If the server store H(H(pass,salt)) and the client sends H(pass,salt), then H(pass,salt) is as sensitive as the original password (it's enough to authenticate) so this scheme transmits something as sensitive as a plaintext password, this is not better than sending plaintext password and storing H(pass,salt)

In fact the scheme is more like this:
The server store H(H(pass,salt)) (let's call it X)
The client sends R = H(X,nonce) XOR H(pass,salt)
The server checks the authentication by doing H(H(X,nonce) XOR R) == X
This way, knowing X is not enough to authenticate on another server (no pass the hash) and R do not reveal the password if the server is a rogue one.

  • I think it is wrong to say that SCRAM address the problem of plaintext-equivalent storage. So there is a mistake in the wikipedia article
    – Sibwara
    Oct 6, 2020 at 14:39
  • I think that you are confusing a few concepts. SCRAM is, in fact, better than storing plaintext passwords in terms of protecting the passwords, not in terms of preventing a hash-replay. The nonce is the key to the whole thing and the section about "channel binding".
    – schroeder
    Oct 6, 2020 at 14:50
  • The wikipedia sentence is "...which makes the stored hashes just as sensitive as the actual passwords. SCRAM is a challenge-response algorithm that avoids this problem". If the server stores H(pass) and the client sends H(nonce+H(pass)) then the stored hash is as sensitive as the actual passwords (everyone knowing it can then authenticate without knowing the original password)
    – Sibwara
    Oct 6, 2020 at 15:54
  • 1
    Fair enough. But you get that ckey is different from H(ckey), right? And only H(ckey) is stored on the server? To send cproof I would need both.
    – schroeder
    Oct 6, 2020 at 16:20
  • I just read the RFC of SCRAM and I understand that I missed the XOR part. In fact server store H(H(pass,salt)) (let's call it X) and the client sends R = H(X,nonce) XOR H(pass,salt). The server checks the authentication by doing H(H(X,nonce) XOR R) == X. It seems correct : hash cannot be replayed and secret is never transmitted directly to the server. But in this case my question is, why SSH is not using this scheme ?
    – Sibwara
    Oct 6, 2020 at 16:36

1 Answer 1


The reason SCRAM prevents pass the hash is that the factors of the hash change due to the challenge. (the counter should be a nonce thereby making it trivial for the real secret holder to calculate a new hash but hard for an attacker to calculate a new hash.)

Repeating the hash (as a Pass-The_hash attack does) should have an extremely small time window / be impossible to do silently. If the attacker has compromised the server all bets are off, regarding security (they have won by that point).

So the Server validates the authenticity of the connection/user by sending a nonce & Iteration count to the client. client uses this to calculate a hash response with the known and unknown elements (password hash) resulting in a once valid hash that the server validates by comparing it with the values it knows (hash of the password and the nonce / iterator).

You could employ another level of hashing. this would ensure that just having the key as stored on disk is not enough to calculate the hash, but since someone probably also has the way you hash it again at that point it is a small difference.

Basically it all boils down to what threats are you trying to protect against, at what cost.

  • I use the term "pass-the-hash" in the way we can reuse SAM hash of a Windows machine against other machines of the network. It is not a "network replay" scheme
    – Sibwara
    Oct 6, 2020 at 14:42
  • if you got physical access to the machine... you can do anything. if thats out of scope for you... everything networked is the same as everything on the machine ... (network complicates it)
    – LvB
    Oct 6, 2020 at 16:49

You must log in to answer this question.

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