There are two classes of algorithms you can use to solve that problem: zero-knowledge proofs and Password Authenticated Key Exchanges (PAKE): https://en.m.

There are two classes of algorithms you can use to solve that problem: zero-knowledge proofs and Password Authenticated Key Exchanges (PAKE): https://en.m.wikipedia.org/wiki/Zero-knowledge_proof https://en.m.wikipedia.org/wiki/Password-authenticated_key_agreement In both, the client proves that it knows the password without ever sending it over the wire. The server also doesn’t store it in plaintext. In the algorithm I’m most familiar with (SRP6a) the plaintext password never leaves the client machine either on initial signup or on later password-based authentication, and what does transit the wire can be used neither to recover the password nor to replay the login attempt. You cannot break into the account just by passively watching the messages go back and forth. https://en.m.wikipedia.org/wiki/Secure_Remote_Password_protocol One of the posts down-thread mentioned SCRAM, which I believe qualifies as a zero-knowledge proof algorithm, not a PAKE, but that’s about all I know about it. https://en.m.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism https://en.m.wikipedia.org/wiki/Salted_Challenge_Response_Au... One nice thing that falls out of a PAKE algorithm, as opposed to a zero-knowledge proof, is that you get a cryptographic key on both sides (thus the “key exchange” part of the acronym) that the peers can use with a symmetric encryption algorithm to communicate with each other. This then lets you construct things like TLS-SRP, which is a variant of TLS (ne SSL) that uses SRP to get the symmetric key instead of X.509 certificates and an entirely different key exchange algorithm: https://en.m.wikipedia.org/wiki/TLS-SRP Incidentally, the use of this sort of algorithm is why so many web sites now prompt for the user name and password on separate screens. There’s usually at least a two-way exchange involved where the user name goes to the server, which provides some bit of cryptographic hoo-hah, which then lets the client prove to the server in a separate exchange that it knows the password. This goes against old guidance to ask for both at once and to reject the login if either the user name or password are incorrect, which avoids giving an attacker a way to probe for valid user names. We lose that in the name of greater security goals.