This question already has an answer here:

In the design of a backend database, the password field suppose to be hashed using bcrypt.

There are two approaches

  • backend only: password = bcrypt(plain_passsword)
  • frontend + backend = password = bcrypt(sha1(plain_password)), where sha1(plain_password) is computed from the client side, e.g. JavaScript

The advantage of second approach is, there is no plain password being sent over the wire, so even the HTTPS is broken, there is no immediately security risk for our users who leaked their plain password.

Edit: My question is different from existing questions as they emphasise on frontend vs backend, but my question is backend vs frontend+backend

marked as duplicate by Steffen Ullrich, Serge Ballesta, Matthew, Mike Ounsworth, Tobi Nary Aug 16 '17 at 13:40

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


There is not much difference in your two solutions you are still essentially just sending the password in plain text over the wire witch ever one you go with. The second solution will only protect other accounts that users have used the same password for but will have no effect on your site.

  • It will better protect users who (often the case) reuse passwords. It also allows stricter request size limits in the server. – eckes Aug 17 '17 at 0:27

There are two problems mixing in your questions :

  • Leak of user password
  • Being able of authenticate against an application of your system

Basically the SHA-1 (or better SHA-2 but aniway) will hide the clear text password from anyone. So well it won't leak the user's password which resolve my first bullet even though it's more the goal of HTTPS to do that.

However for the second bullet, it doesn't add anything, because an attacker will just need to send the SHA-1-hashed password against your applications to be able to authenticate, because a hacker don't need specifically a clear text password, he needs what the server will accept.


I get your idea, hashing twice to try and get both benefits. But if you send the SHA1 hash to the server for authentication, that is now the plaintext password for your application.

So security-wise, there are no benefits except protecting the other accounts the user might have re-used his password for. It adds nothing to the security of your application.

Not the answer you're looking for? Browse other questions tagged or ask your own question.