Why do systems that do password authentication actually send the password over the wire?
Why not just have the server issue a challenge, and have the client append append that challenge to the password and reply with its SHA256 hash, to protect against MITM leakage of the password?
Is there any benefit to actually sending the password? (It seems e.g. SSH does this? Why?)
The reason for passwords sent either in plain text or hashed are mainly historical. In the old days when we used dumb terminal over serial lines (70's to 80's), only plain text solutions were possible. Well One Time Password like S/Key also existed but you needed the hardcopy list with you...
Then came the era of PC, Windows and Lan Manager. Microsoft fellows knew that ethernet networks were too easy to spy, so they decided to only exchange challenges. The counterpart was that is was necessary to store the password in an invertible form on the server.
The usage of crypto became more popular with SSL, and many protocols were adapted to use encrypted channels (HTTP -> HTTPS for example). And admins re-discovered the benefits of only storing hashes on their servers: if the password database is compromised, you have plenty of time to change the passwords.
That's the reason why best practices are nowadays to exchange password over encrypted channels and store salted hashes on servers, and why other practices have existed...
Today I asked myself the same question because we put a honeypot in our network and it raised us the Lansweeper SSH password (which is available over all the unix boxes...).
So it is a way for an attacker to get sensitive passwords in a corporate network.
I was like "... WTF SSH does not use challenge response ?". Then I though a little and say "...ok 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".
AND
I read about SCRAM which consist of the server sending its salt and the round number of bcrypt and the client must send the result.
... it seems to be exactly the same problem as the hash is the secret. So I guess wikipedia made a mistake in this sentence:
"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"
EDIT: i'm wrong SCRAM does permit to store a hash which cannot be replayed AND make the client not revealing the secret during authentication.
The simplified scheme is like:
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.
The main reason may be, that whatever you do on client side, can be easily circumvented if you are not using an encrypted HTTPS connection. The JavaScript can be modified or removed completely by a ManInTheMiddle attacker.
So the only thing you can rely on is the encrypted HTTPS/SSL connection. If you do not have the connection encrypted, all client side actions are pretty useless, if you do have a HTTPS connection, the client side actions do little to improve security.
This applies typically to websites, it is another case when the user installed a client software on his computer. With a client software installed, there is no need to exchange code (JavaScript).
(Self-answered question...)
I believe this is because then you can't salt and hash the password on the server side.
Notice salting is still necessary here because if the server-side password is stolen then it can still be used for login even in the challenge-response scenario.
You have a few problems there.
The server needs to have your password to validate the hash you send to it. While SSH accounts are configured locally on the system before remote access, your common web app will have a registration form, and in this case you'll need to send the password in plain text, defeating the purpose of your suggested digest authentication.
The same applies to password editing.
The second problem is that, if you use an unsecured transport method, I still can MITM you and inject any javascript I like on the web page, getting your username, password and everything else.
MITM is a well understood attack vector, and already has a solution: TLS.
This way the whole page will be encrypted and signed, so an eventual attacker can't see or edit anything, protecting the whole data stream going back and forth, and rendering digest authentication redundant.
Why do systems that do password authentication actually send the password over the wire? Why not just have the server issue a challenge...
Let me reverse the question. What would you gain by not sending the password over the wire? The answer will often be nothing.
The primary place where we use password is on the internet. When you visit a web page, this page is controlled by the server and hence you can consider it an extension of the server. If the server is compromised or evil, as soon as you type the password on the page, you can consider it compromised and this password should be changed.
In your question you seem to worry about MitM attack, but only consider the MitM that can append when you submit the form and not when you receive the page, but both are as deadly. It doesn't matter if your password is not "supposed" to be sent or not, as soon as it's typed it's same thing.
So is it totally useless to use challenge-response authentication on a webpage?
If you use TLS, I would say yes. Remember the client is just an extension of the server.
If you don't use TLS, it can help against passive eavesdropping but is still useless against active MitM; where you can modify the content of the page. The fact that active MitM is much harder to pull off than passive eavesdropping was a reason that motivated the creation of such scheme. See digest authentication.
Why is SSH different?
Because the server doesn't control the client. The client is completely separated from the server. This means that when I typed my secret password in the client, even if I response to a challenge from an evil server, my secret password is still safe.
It's the same thing with your credit card. The smart chip on your credit card contains a secret key that is used to answer a challenge-response every time you make a purchase. This secret key is protected even if you make a purchase from an evil terminal.
Note : An advantage of the challenge-response mechanism is also that it lets the user reuse the same password with multiple server. This point is need for credit card for example as they will use many terminals (servers) and only have one password.
Challenge-response mechanism only work when the server doesn't control the client.
This means that if we wanted to use challenge-response authentication for webpage, it would need to be implemented at the browser level and not the web page level. Whether that would be a good idea or not is a completely different question.
I believe this is because then you can't salt and hash the password on the server side.
It's true that if you use symmetric encryption, you won't be able to protect the password correctly on the server as you need it to verify the answer of the challenge. That's why you use asymmetric encryption for challenge-response scheme. For example, both SSH and your credit card are using asymmetric encryption. With asymmetric encryption, you can store the public key on the server and the user can keep it's private key... private.
