Sending password to server vs. sending SHA

This is an existing website with approx. 100K accounts, and passwords are hashed using bcrypt with a high number of rounds.

The current design that I'm questioning is that we're sending the username and password to the server, and doing the bcrypt on the server, instead of sending a SHA generated in the browser and bcrypting that, so that we never touch the user's password.

The original rationale was that if we're sending a SHA, then the SHA just becomes the password, and nothing is gained. But that doesn't seem true.

We see pretty routinely that people try to log in to our website using their Apple or Google username/password combo, because they don't fully understand the difference between our systems and Apple/Google's systems.

Now, their clear-text password does hit a highly isolated system behind the AWS load balancer, and this is even more isolated in the future. We touch the clear-text password for a microsecond and then forget.

But it still makes me queasy. So the question is, what's the remedy?

• Would sending a SHA to the server be better, so that we at least never see the password server-side, even briefly?

• What would a migration path look like, beyond changing this and resetting all passwords, requiring users to create new passwords whose bcrypt is now based on a SHA?

• Any other ideas?

Would sending a SHA to the server be better

No.

If the hashing is done server side & the server's password database leaks, it's useless because a client cannot use the hash for logging in because client has to send the password & not the hash for logging in.

If the hashing is done on the client side & the server's password database leaks, then a fake client can login by sending the hashes to the server.

So that way is less secure.

Any other ideas?

PAKE - Password Authenticated Key Exchange - https://eprint.iacr.org/2018/163.pdf

TLDR

If you want to choose between two methods only, sending plain password or sending password hash, then sending hash is better.

Details

If there is a mistake on the server side and the password was written to a log, this may give some insights about how particular user generates passwords: What characters are used, how long the passwords are, how much are the passwords indistinguishable from a random sequence.

Besides, as you mentioned, some users may reuse their password for multiple systems. If mistakenly written to the log, this may be a security problem.

If users send hashes, you will avoid these potential problems.

About brute-forcing: SHA is very fast by design. That's why trying some character sequence as a password directly, i.e. applying bcrypt directly, or first hashing with SHA and then applying bcrypt, will take similar amount of resources. In both cases the success of brute-forcing will primarily depend on the cost factor that you use in bcrypt.

But if you want that the client doesn't send even the hash, consider what the others suggested, PAKE / OPAQUE.

To avoid the risk related to password reuse and thus password shucking, you can add a salt during pre-hashing, e.g. user you application name or domain name as a salt. Then for the same password with the same hashing function you will get a different hash value.

If you are designing from scratch then try this -

Server-Side/Back-End :

Store the passwords using password-based-encryption or HMAC-HASH (derive a key from the password + use a salt that is known publicly but specific to your organization).

This way even if the user has re-used passwords and the database is compromised (last-pass is the most recent one as of writing), the hacker cannot mount a dictionary attack.

Client-Side/Front-End

The reason for the salt being public is simply because that's the only way we can repeat the process at the client end.

Hence, once the user enters the password, repeat the process (the client has the public salt and the password hashing/key-derivation algorithm).

This way the clear password never reaches the server (which I guess is what you are looking for).

Rollout-Strategy

This would be a prolonged one. You can auto-enroll all users at the point of successful login to the new system. But you'll need to retain old user's on the older setup/format. Also you'll need to handle both old and new format's at the client and server end (have some kind of a flag to determine whether the user is on the older setup or the new one). If two-steps are fine, you could first ask the user for the email and then figure out which system they are on (old or new) and subsequently prompt the user for the password accordingly !

Update 29-Dec-2022 :

To address the concern mentioned in the comments, where the database itself is compromised, we can introduce the following modifications to the scheme -

1. Include the User-Id as part of the the public-salt. This way each password will effectively have its own salt ! So what is sent to the server is effectively - hash(hash({#clear-password}), {#user-id}, {#server-public-salt})

   Let's call this resulting value as client-user-credentials.

2. The server while storing, will now apply a private hash on the above user-secret and then store. So the server effectively stores - hash({#client-user-credentials}, {#server-private-salt})

3. Going forward, the client always calculates client-user-credentials and transmits to server. This does not remove the possibility of man-in-the-middle scenarios but does address the concern that even in the event of a database breach, it would not be possible for the hacker to mount an attack that would compromise the account.

There is still however a possibility that if at all the server is compromised, the hacker can linger for some time and capture the clear client-user-credentials but that would be difficult to solve and perhaps other schemes suggested else-where in the answers can be used.