Safety of Password Hashing Using bcrypt Done on Client Side

Question

I am currently using a technique where I send the username/password in cleartext (using https) to the server, which then does bcrypt and compares to the db. Standard practice.

It is considered safe.

Would sending bcrypt hash to the server for checking be equally safe?

The point of bcrypt is that it is computationally expensive, so that stolen hashes cannot be brute forced (or would take a long time). With the client sending the hash, i think this still holds true.

So, the question is, would this technique compromise my network's security in any way?

-- Edit

I would like to do this because it reduces the computational power the server needs. Doing moderately expensive things on the client is never a bad idea.

Answer 1

The issue is that your hash now essentially becomes your password. If your database of hashes gets stolen, they don't need to worry about brute-forcing any of the hashes, because that's all you need to send now to authenticate.

Answer 2

This post should answer your question: https security - should password be hashed server-side or client-side?

Basically, if you hash on the client side the hashed password becomes the authentication token and it means that you are in essence storing the password in plain text in the database.

So to answer your question: It would not compromise your network's security but it would mean that if your database is breached you have lost all the benefit of storing the password in a hashed format in the first place since the hashes are now the passwords.

Answer 3

I think now you already know from the answers, why it can be a problem to send password hash to the server. I would just like to comment on this particular point:

I would like to do this because it reduces the computational power the server needs. Doing moderately expensive things on the client is never a bad idea.

The fact that bcrypt (an adaptive hash function) is slow and consumes more server's computational power can make your server vulnerable to an easy DoS attack. Since this makes password verfication a more computational intensive task, an attacker can send many login requests to the server and trick the server into doing more work than expected. You can find more details about the problem in the following threads:

Can client-side hashing reduce the denial-of-service risk with slow hashes?

Should you care about DoS attacks if your server is using bcrypt?

So, instead of hashing passwords at the client-side, you can make use of a proof-of-work scheme where your browser performs a bunch of computations and provides proof to the server that the server can very quickly verify in the same request where the password is submitted. This way, the server will only compute the bcrypt if the PoW is verified. This can prevent server from DoS since the client will have to do some work as well. For the devices with less computational power (which might not be suitable for computing the proof of work), you can use schemes such as CAPTCHA.