8

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.

code ninja
  • 213
  • 2
  • 7
  • 2
    See [this question](http://security.stackexchange.com/questions/58704/can-client-side-hashing-reduce-the-denial-of-service-risk-with-slow-hashes) BTW, your terminology of "cleartext over HTTPS" is extremely confusing. HTTPS is certainly not cleartext. – paj28 Aug 07 '14 at 14:42
  • 2
    Well its cleartext, because it is sent and received (as far as the application code is concerned..). The transport is encrypting the data.. So to a man in the middle, it is encrypted. – code ninja Aug 07 '14 at 14:57

3 Answers3

21

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.

Greg
  • 869
  • 7
  • 10
  • 2
    I was thinking about this, if OP just hashes the bcrypt hashed password on his server with a less computationally expensive, but cryptographicallly secure hashing algo like SHA-2, then he'd solve this problem. – Joe Thomas Aug 16 '17 at 17:10
  • @JoeThomas then that's about as insecure as using SHA-2 to hash the user password without client-side hashing, with only the risk of password reuse removed. – SOFe Mar 24 '21 at 09:03
7

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.

Community
  • 1
ilikebeets
  • 2,746
  • 16
  • 22
5

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.

Community
  • 1
Rahil Arora
  • 4,307
  • 2
  • 23
  • 41
  • Interesting notes about DoS. There is a rate-limiter on the IP and the login username.. So if either IP or username gets exhausted, any access is denied. – code ninja Aug 07 '14 at 14:58
  • True. But that will still be vulnerable if the attacker has control over a Botnet! – Rahil Arora Aug 07 '14 at 15:14