0

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.

DeusXMachina
  • 101
  • 2
  • Are "increased code complexity" or "increased attack surface" valid reasons, or are you looking specifically for crypto-related issues? – user Jul 30 '20 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. – DeusXMachina Jul 30 '20 at 19:08
  • This is a security site. Our answers will be security-related, not development-related. – schroeder Jul 30 '20 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) – DeusXMachina Jul 30 '20 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 '20 at 19:35
  • So in short, no, there is no harm, provided you take all the same precautions as you would with an un-client-hashed-password. Right? – DeusXMachina Jul 30 '20 at 20:34
  • @DeusXMachina Depends on if your hash is secure. If it generates a lot of collisions then you could potentially reduce your security. For a very contrived example, consider a hashing algorithm that only has 1 byte output, then there would be 256 possible "passwords" that get sent to your server. Theoretically it would also be possible for an attacker to use side channel or timing attacks to infer data from the client. – user Jul 31 '20 at 12:38
  • Yeah, but I wouldn't use such a thing for this purpose, hence `cryptohash`. I would use a cryptographically secure hash like Argon2, PBKDF2, or bcrypt. – DeusXMachina Jul 31 '20 at 14:43

0 Answers0