Is this Wikipedia article about SCRAM wrong?

Question

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.

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.