Authentication without decrypting the password?

Question

To my knowledge it works like this:

1. The server receives the username-password values over a secure & encrypted channel.
2. The username-password values are decrypted in the server and are present as plaintext.
3. With the username the according salt gets retrieved for the user.
4. The salt is appended to the plaintext-password and is finally hashed.
5. The hash is compared to the stored hash and depending if the hashes match or not the user gets logged in or receives some sort of a message that says that the username / password is wrong.

Hypothetical problem: If for example we have a vicious programmer "Mallory" that works as a programmer for the company he could write a piece of code inside the authentication process to receive the plaintext password:

private bool Authentication(string username, string password)
{
    // Some code ...

    log($"{username}, {password}"); // Logs the plaintext username & password for Mallory

    // Some more code ...
}

For this example we assume that the company fully trusts Mallory and that nobody else ever checks the source code.

---

My questions are:

• Is it possible to change this authentication mechanism in a way so that the password is never present as plaintext?

• Is it possible to prevent this without changing the effort for a user, like introducing two-factor-authentication or something similar?

Answer 1

This can be done with a cryptographic protocol called Password-Authenticated Key Exchange (PAKE). It comes in a few flavors:

• Plain PAKE is a good fit for peer-to-peer connections. Both participants know the password in the clear, and use it as input to the PAKE protocol. If they both agree on the password, then they establish a shared secret key, safe from eavesdroppers. If the passwords disagree, they fail to establish a key.

• Asymmetric PAKE (aPAKE) is a good fit for client-server connections. The client knows the password in the clear and the server holds only a "hash" of the password. (In practice, it's not exactly a hash but something more involved. The point is that the server doesn't know the password in the clear.) The two participants will establish a shared secret key only if the connecting client uses the correct password.

A good, accessible introduction to the state of the art can be found in this talk by Hugo Krawczyk earlier this month at the Real World Crypto symposium. Among other things that you can do with PAKE, he explicitly talks about aPAKE as a replacement for password-over-TLS (the typical approach for authentication that you described).

Answer 2

Secure Remote Password (SRP6a) protocol solves this. It is used as a mechanism for TLS negotiations in RFC 5054 and was added into OpenSSL. RFC 2945 covers password authentication although modern implementations will use a stronger hash function.

You can perform the protocol efficiently in JavaScript in a browser to authenticate against a webserver. Here is demo code of a browser authenticating against a Java server running Spring Security which is a mainstream technology in some large financial services companies.

It is quite remarkable that the protocol has been around a long time but isn’t widely known. People assume TLS is good enough despite the fact that there are many scenarios that lead to a stolen password even with correctly configured TLS.