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

  • you're supposed to be using TLS when sending passwords anyway, so it's not needed. – dandavis Feb 20 '17 at 13:37
  • 1
    @dandavis: Since when does SSH use TLS though? All of you telling me about TLS are completely missing the entire point of my question. I merely suggested MITM mitigation as a side benefit of doing password auth differently... I was not trying to solve the MITM problem or claiming that this is the best solution to the problem. The goal was to understand why password authentication, not to solve MITM.. – Mehrdad Feb 20 '17 at 17:50
  • 5
    Voting to reopen the question as the "duplicate" hardly answer this question. The duplicate focus on whether or not to use basic http authentication vs digest authentication. While it's similar to this question it is too narrow to answer this question. More specifically it fails to address the reason why challenge response don't usually offer more security and why SSH is a different case. – Gudradain Feb 20 '17 at 18:38
  • @Mehrdad as I replied in the comments below I can't understand your question. What is the problem you're trying to solve? If you don't specify any, the answer will always be the same: You don't solve a problem that isn't even there. Serge Ballesta in his answer told you why digest auth was introduced historically, and why digest auth is not a common way to authenticate nowadays. – BgrWorker Feb 21 '17 at 7:46

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

  • I'm confused here. You talk about the 1970s/1980s and Windows and SSL, whereas the example I gave (SSH) was built in 1995 and a *nix tool that doesn't use SSL... are you answering the right question? – Mehrdad Feb 20 '17 at 17:57
  • @Mehrdad: You have plenty of answers (including yours) explaining why it is better to exchange a password and only store salted hashes. I just wanted to explain why other solutions exist (or have existed...) – Serge Ballesta Feb 20 '17 at 18:51

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.

  • as you describe, sending it plain would only be needed upon creation and modification. – dandavis Feb 20 '17 at 13:38
  • @dandavis: Hm, I don't follow. If the client don't send the password to let the server check the salt when authenticating, the server's only alternatives are to either (1) store the password itself, or (2) store the salted hash, but pass the salt back and then the client do the hashing and send it back to the server. Both of these mean that if the credentials are stolen from the server, they can be used to log in later... which defeats the point of salting. Am I missing something? – Mehrdad Feb 20 '17 at 18:06
  • 2
    the server can store a hash of a hash, re-created on-demand. – dandavis Feb 20 '17 at 19:09
  • Your answer is just a part of the full answer. I might answer if they decide to reopen it... – Gudradain Feb 20 '17 at 19:12
  • 1
    @dandavis: I don't follow. Post an answer and explain why the first hash wouldn't be equivalent to the password itself? – Mehrdad Feb 20 '17 at 20:03

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.

  • TLS? Since when does SSH use TLS? I was merely offering a potential benefit of doing password auth differently and asking why it wasn't done that way; the point wasn't to solve the MITM problem here. – Mehrdad Feb 20 '17 at 17:42
  • @Mehrdad your question was generic, and I replied in a generic way. If your question was for SSH only, please specify. The point is always the same anyway: it uses transport layer encryption. It also uses digest authentication because it brings no usability downsides, but as I described this would be a problem in a generic scenario where the server doesn't know your password in advance. If the problem you want to solve isn't defeating MITM, you should specify the attack vector you want to mitigate. "Increasing security" is not a reason. – BgrWorker Feb 21 '17 at 7:40

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.