> If the client could simply send a hashed password over as an authenticator, then hashing the password database would provide no protection against theft, beca

> If the client could simply send a hashed password over as an authenticator, then hashing the password database would provide no protection against theft, because you could simply use the stored hash as the password. I'm not sure I understand this sentence. Are you reading the parent message as proposing hashing client-side using the same algorithm as the server-side hash and comparing directly on the server against the database-stored hash. This would be outrageously stupid of course, but I'm certain the commenter was not proposing that. They said: > hash on the client side first to avoid sending the password to the server, and then hash again on the server. Note, hashing again on the server. To describe this slightly differently, think of the clientside algorithm as effectively being a password generator, with the user inputting their own memorable password as a kind of encryption* key for their "real" auth API password—the main advantage is fighting password reuse. *encryption!=hashing but I'm just using the term here to illustrate intent.