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.

>then a hacker stealing password hashes would enable them to instantly log in, without cracking them

How do you know the hashed value stored in the database is the same hashed value the user submitted? Server side I can add a salt and hash more before storing or comparing.

> How do you know the hashed value stored in the database is the same hashed value the user submitted?

Please explain how authentication would occur without a comparison between the user's submission and a value stored at creation/update of the passphrase.

There is a comparison.

> 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.

Sure, you could MITM still if all you do is that, as with anything it depends on what you are defending against.

If you are defending against clear text being discoverable, then bcrypt hashing with a unique salt on the client is good enough.

If you are trying to prevent MITM you can combine that salting with public/private key transmission of the bcrypt hash to the backend (effectively the same idea as pass keys without the downsides).

MITM just affects your service, and doesn't always matter depending on what the service is, for example, a recipe manager doesn't need to have bullet proof security.

As the hash is being encrypted with the public key in the client, that would require that the client be compromised. In which case the original password is already exposed at that point, thus a discussion of the transport is no longer the concern.

The point of a hash is that the password is not stored on the machine long term. Thus, if an attacker gains access to the back-end and exports all the hashes, you can't reuse the hashes themselves to login. I.e. you need to do a password-cracking attack, which is infeasible with a password of sufficient length.

I don't care if someone gets my password hash. They aren't going to crack it due to the complexity of it.

Here is my hashed password. Good luck:

    $argon2id$v=19$m=65536,t=3,p=1$YTE4NzBkMDIwMjRhMGY5NzU4OTc2ZWY5YzI0N2RjOTY$GSBlUwWxr4BBs+5o5Ye2NphT9PFeWx4ECG6siED9uVQ

You can't use that to login to my system. You can only use it to validate if I give you my password...

Correct. The hash effectively is the password at that point.

If you’re storing the hash unencrypted in the DB, and it’s “just” a hash so why not, you’ve gone backwards.

> 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.

I immediately emptied my account with BBVA (a major bank with $37B yearly revenue) after their app asked me to validate my identity by entering "the fourth character of your password". Subsequent attempts asked for different ordinals. This was in 2023.

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

A phpBB forum era classic!

It adds a vintage character to otherwise modern and boring websites. This happened to me as recent as last week, BTW.

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"

Hash the hash.

This would work, but the first stage hash is effectively the password at this point.

    Client:
        C = SHA256(password)
    
    Server:
        V = Argon2id(C, server_salt)
    
    Database:
        stores V and server_salt

Good I still don't want to know the password. If the first stage hash is compromised there are bigger issues, bigger than even if the database of hashes or passwords got hacked.

> 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.

The mechanism proposed by the GP is not competence. It's a well-known vulnerability called "pass the hash".

But the sites where I actually care if my account gets compromised - Steam, FastMail, DigitalOcean etc. - are very unlikely to screw up password storage.

I'm never going to bother with paranoid security inconveniences for the crappy website my local pizza place uses.