3

I've read these:

https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

https://security.stackexchange.com/questions/8596/https-security-should-password-be-hashed-server-side-or-client-side

Is it worth hashing passwords on the client side

Password encryption at client side

https://softwareengineering.stackexchange.com/questions/76939/why-almost-no-webpages-hash-passwords-in-the-client-before-submitting-and-hashi

... and I STILL think that hashing your password on the client side is better. Let me explain.

The first cited article advocates that you should make the login page stand alone since there's no way to trust the entire codebase used in the client side. I think it makes sense.

And if it makes sense, how can you trust the entire codebase used in the server side?

So many upvoted answers above are claiming that "don't hash on client side, because TLS exists". That's true for preventing the password from sniffed, but is not related at all if it's about our potentially-evil server side code.

Also, I don't see any reason for the server side to hash the password if it's hashed already. If your server is cracked, you're done - regardless of the passwords - but the cracker can't use the obtained passwords anywhere else.

But since I can find no such answer, my statement seems to be fundamentally wrong. What am I missing?

akai
  • 2,498
  • 4
  • 24
  • 46
  • Hey, why downvote? – akai Feb 04 '18 at 12:40
  • This question should be on-topic on security.stackexchange.com (and to a lesser extent on crypto.stackexchange.com), but it's off-topic on SO as opinion based. (That said, I'm certainly with Anti-weakpasswords on this, though I don't think you need high work factors on the server; IMO a simple SHA-256 on the server is adequate if PBKDF2 were run on the client.) – Rob Napier Feb 05 '18 at 01:27
  • you're right, thanks. – akai Feb 05 '18 at 13:03
  • @RobNapier - On the general premise of "never trust the [possibly compromised or third party clone or otherwise compatible but not identical] client", I would quite strongly say that the server has to be secure in and of itself. The court of public opinion won't care about "but the client was supposed to do that" if the client was compromised and/or someone else's compatible client was used instead. Additionally, if the server operator insists on the absolute minimum being done on the server, trusting the client 100%, I would still use at minimum HMAC-SHA-256 or, better, HMAC-SHA-512, salted – Anti-weakpasswords Feb 07 '18 at 03:51

1 Answers1

12

If you think hashing BOTH client AND server side with a modern password hashing algorithm like PBKDF2, BCrypt, SCrypt, or Argon2 with a high work factor/iteration count is better, then I agree.

If you think hashing ONLY client side is better, then I have serious reservations about your threat model.

There are threats that hashing passwords server-side protects against, and threats that client-side protects against; here's a brief list:

  • BOTH: leaked password database entries allowing viewers to see what the user typed in cleartext.
  • CLIENT: Server-side insiders with packet/traffic interception access seeing what the user typed in directly
    • This is one of the two major threats that client side hashing IN ADDITION to server side hashing is a good fit for mitigating.
  • SERVER: Insiders with database access fradulently impersonating actual users
    • if passwords are ONLY hashed client side, then whatever's in the server DB can be fed to the system via the client request to log in as the user "legitimately" according to the server. This makes all server audit logs of who did what suspect.
    • if passwords are hashed server side, regardless of what happened client side, what is in the server does NOT authenticate the user if fed in via the normal authentication channel.
  • CLIENT: MitM attacks seeing what the user actually typed in
    • This is the other major threats that client side hashing IN ADDITION to server side hashing is a good fit for mitigating.
    • MitM attacks can come from the client's corporate IT department, a network provider or other ISP, the server organization's IT department (load balancers or advanced security appliances with the actual cert key, etc.), or many other sources.
  • NEITHER: MitM attackers fradulently impersonating actual users
    • No matter whether you hash it client side or not, what gets sent over the network to the server app IS what the server uses to authenticate you.
Anti-weakpasswords
  • 2,604
  • 20
  • 25
  • I'm with you about hashing on both client and server, and with your excellent collection of attack vectors, but I would argue that SHA-256 (or -512) is sufficient on the server if PBKDF2 (or other KDF) has been run on the client. I don't believe there's any benefit to adding an expensive KDF step on the server when dealing with an already-hashed (and therefore "indistinguishable from random") value from the client. A simple (and fast) cryptographic hash at that point should address all the concerns above. – Rob Napier Feb 05 '18 at 01:30
  • 1
    @RobNapier - On the general premise of "never trust the [possibly compromised or third party clone or otherwise compatible but not identical] client", I would quite strongly say that the server has to be secure in and of itself. The court of public opinion won't care about "but the client was supposed to do that" if the client was compromised and/or someone else's compatible client was used instead. Additionally, if the server operator insists on the absolute minimum being done on the server, trusting the client 100%, I would still use at minimum HMAC-SHA-256 or, better, HMAC-SHA-512, salted – Anti-weakpasswords Feb 07 '18 at 03:51
  • 2
    I don't think this is a case of trusting the client. You're right that if someone modifies their client to make it less secure, then they can somewhat (but not completely) reduce the security of their own account. If they send the server passwords in the clear, I don't think the server should go to great lengths (and PKBDF2 on the server with any non-trivial number of iterations is a great length) to stop them. I think your argument to salt the server-side hash is clever and useful (I'll have to think about adding that to my list), but why HMAC rather than just SHA in this case? – Rob Napier Feb 07 '18 at 14:04
  • 1
    For this to be an attack (rather than someone being foolish with their own client implementation), it would have to involve someone seeding a compromised client to users, then stealing the server's account database. But if they've seeded a compromised client to users, stealing the raw password is trivial; there's no reason to weaken the hashing to allow easier password cracking later. They have the password already. – Rob Napier Feb 07 '18 at 14:07
  • (Making "passwords must be precisely this long and a string a hex digits" a simple check in the API would also almost certainly prevent custom clients from messing up their own implementations, and so seems like a good practice to address the valid concerns you're raising about custom clients.) – Rob Napier Feb 07 '18 at 14:09
  • @RobNapier - good practice, sure, but you will be 100% unable to tell the difference between one iteration by the client and one million iterations by the client, or even a client who does MD5 on the first half and the last half of the password and then sends that result, even if you put in enough checks that "take the password, pad it to length, and send it in hex" is caught (which your initial length + hex digits check would pass). – Anti-weakpasswords Feb 09 '18 at 03:15