Authentication without decrypting the password? To my knowledge it works like this:


The server receives the username-password values over a secure &amp; encrypted channel.
The username-password values are decrypted in the server and are present as plaintext.
With the username the according salt gets retrieved for the user.
The salt is appended to the plaintext-password and is finally hashed.
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 &amp; 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?
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).