-2

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

Ryan
  • 467
  • 1
  • 5
  • 13
  • Did you try to search for *client-side hashing*? I'm pretty sure we already have plenty of duplicates that might help you. – Arminius Aug 16 '17 at 03:48
  • 10
    Possible duplicate of [Why is client-side hashing of a password so uncommon?](https://security.stackexchange.com/questions/53594/), [When and where do I hash a password?](https://security.stackexchange.com/questions/54095), [Password hashing on frontend or backend?](https://security.stackexchange.com/questions/110948), [What to transfer? Password or its hash?](https://security.stackexchange.com/questions/23006) and [many many others](https://www.google.com/search?q=site%3Asecurity.stackexchange.com+hash+password+on+client) – Steffen Ullrich Aug 16 '17 at 04:14
  • Update: My question is different from existing questions as they emphasise on frontend vs backend, but my question is backend vs frontend+backend – Ryan Aug 16 '17 at 07:11
  • 1
    At the very least, SHA1 is not suitable for anything security related. – Numeron Aug 16 '17 at 07:25
  • 1
    @Ryan Your question, as you formulated it (including your update), has its answer in the duplicates listed in the comment by Steffen Ullrich. Please read them again. – A. Hersean Aug 16 '17 at 07:49
  • @Numeron SHA1 is just fine in this case as it does not depend on collision resistance for this case where you only want to protect against revealing the preImage. In fact even using md5 in this scenario is not uncommon as it is fast in JS (I think Facebook still does it) – eckes Aug 17 '17 at 00:26

3 Answers3

1

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.

Dam30n
  • 411
  • 3
  • 3
  • 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 00:27
1

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.

Walfrat
  • 406
  • 2
  • 12
0

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.

J.A.K.
  • 4,793
  • 13
  • 30