That's not accurate. If that were true, then a hacker stealing password hashes would enable them to instantly log in, without cracking them. Rainbow tables and dictionary attacks exist for a reason.

Pass-the-hash has been tried in NTLMv1 and thankfully that was the end of that failed experiment.

Modern password authentication is performed by the client sending a plaintext password encapsulated within a symmetrically-encrypted tunnel. On the Web that's with TLS. The server then uses bcrypt or another scheme to hash the password (along with the stored salt) and compared that resulting hash with the value in the table.

This is incorrect implementation fyi.

You are supposed to send the password, via TLS so it's not in the clear, to the server to be hashed.

If you hash on the client... then the hash essentially becomes the password, and defeats the purpose of a hash. I could just steal the hash and use it.

The name of this vulnerability is "pass the hash"

> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.

Unless I'm misunderstanding what you're doing, this achieves nothing.

Hashing the password on the client side makes the hash the password, and MITM attacks are still possible.

> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.

While rare, a couple of sites which has many (>1000) users have sent me my password in the plain when I told I forgot them.

Many sites have e-mailed my password in the open when I registered, as well.

I don't defend passkeys here, but too many weak links are present in password based flows today. If someone uses per-site strong passwords, one can contain the leaks, but use the password even once, and the problem grows exponentially.

> Whenever I've written authentication, passwords are hashed on the client side and never transmitted in the clear.

Don't assume everyone coding a login page is as competent as you though...sadly.