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.
