This question asks whether one should hash on the client or the server. I want to know if there is any reason, aside from having to maybe handle one extra hashing library (if it's not already in your security stack), why you wouldn't want to hash both on the client and on the server. Extra code complexity is fine, you are just invoking one extra pure-functional method.

Workflow: User submits username/password. Assert the usual password strength check. Submit HTTPS username=username and password2=cryptohash(password). Backend generates salt := make_nonce() and stores username=username, salt=salt, key=cryptohash(password2 + salt).

I ask because I still see lots of websites which set a maximum number of characters to some obnoxiously small number, like 16, 14, 10, or even 8 (I'm fine if you want to cap at 64). Also many limit the types of characters you can input. Ostensibly, this is to protect against buffer overflows, escapes, injection attacks, etc, as well as avoid under-defined internationalization behavior. But why not just take that field and run SomeHash.ComputeHash(Encoding.Unicode.GetBytes(value)), ideally a key-derivation function? That'll take any trash you could put into that field and yield nice random bytes.

This question and this question are kinda similar, but mostly addresses whether you'd want to do only client-side hashing from a security point of view. I'm assuming the security would be at-least-as-good-as regular password form submission.

  • Are "increased code complexity" or "increased attack surface" valid reasons, or are you looking specifically for crypto-related issues?
    – user
    Jul 30, 2020 at 19:05
  • I'm mentioned "increased code complexity". "Increased attack surface" is exactly the kind of things I'm looking for. Maybe I should rephrase the question to address that. Jul 30, 2020 at 19:08
  • This is a security site. Our answers will be security-related, not development-related.
    – schroeder
    Jul 30, 2020 at 19:11
  • That's why I'm saying I don't care about the development side of things. I'm asking if there are any reasons why adding an extra hashing step would decrease your security (aside from the obvious risk of someone injecting bad code into your crypto hash dependency) Jul 30, 2020 at 19:12
  • I think the provided duplicates provide the answers you seek. They outline the weaknesses inherent with the approach and why you would want to. Primarily, if you hash client-side, you do it when you don't trust the server or the network that TLS is being run on. But it's the server, and the network, that's providing the client-side hashing code.
    – schroeder
    Jul 30, 2020 at 19:35