I STILL think hashing password on client side is better. Am I wrong?

Question

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?

Answer 1

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.