You can solve this limitation yourself by implementing a simple client side digest hash before sending to the backend for proper password hashing. So your backend receives the fixed length digest hash and not the actual password for hashing. With a good digest hash algorithm like sha256 you are effectively able to support "infinitely" long passwords without any significant loss of entropy.
>like sha256 you are effectively able to support "infinitely" long passwords without any significant loss of entropy.
I disagree. I used to have my password manager generate long passwords, but I realized that the entropy was just being clipped to 256 bits by the hash function. It's not that crazy to go over. That being said 256 bits of entropy is plenty.
The problem with this approach is that now someone on the backend will mistakenly think, hey the password is already hashed by the client, let's just store that directly in the database! And now you essentially have passwords stored in plain text.
> like sha256 you are effectively able to support "infinitely" long passwords
If my math is correct, 256bits of hash can effectively support up to about a 36-character password, depending on how many bits of entropy you give each character.
Your math is incorrect. Sha256 can support arbitrarily long inputs. You can easily verify this claim by googling a Sha256 calculator and giving it 2 inputs
: First your 36-character "password" and next the same password with an extra character. You will notice that the outputs will be different.
With a password longer than about 36 characters, the pigeonhole principle comes into play, and there will exist a sub-36-length character password with the same hash as the longer password.
Right, but that doesn't refute the original point: you can support infinitely long passwords by hashing them. If we compare truncating a password to 36 characters vs hashing a password to a 36-character hash, hashing is much better. The hash is guaranteed to have at least as much entropy as the original password, up to 36 characters of entropy (yes, the hash can not have more than 36 characters of entropy, we get it, that's not the point, nobody is brute-forcing passwords that actually have 36 characters of entropy).
I'll provide an edge case example to prove my point: suppose someone has a password that repeats the character 'q' 100 times, then repeats the character 'a' 100 times, and so on, until the password contains 8 randomly selected characters. This password has (slightly more than) 8 characters of entropy, right? If you truncate the password to 36 characters, the password will simply be 'q' repeated 36 times, so the truncated password will have (slightly more than) 1 character of entropy, right? But if you hash the 800-character input to a 36-character hash, the hash will contain exactly as much entropy as the input: (slightly more than) 8 characters worth.
Maybe the example with 36 characters doesn't seem realistic to you, but my previous bank (Handelsbanken) actually secretly truncated passwords to 8 characters. I was not aware of this, and I had a password that contained multiple consecutive words (like correcthorsebatterystaple). I thought I had a secure password, little did I know my password was actually a single word because of the truncation. Now, if my bank had instead hashed user inputs to an 8-character hash, and used that as the password to their legacy system that only supports passwords up to 8 characters, my password would have actually contained 8 characters of entropy.
Yes exactly. Hence the quotes around the infinitely.
Your chances of starting out with more entropy in a 800 char passphrase is likely to be larger than what you are likely to have when starting with a 36 char passphrase.
If you hash a 36 char passphrase then you retain most of the entropy of that 36 chars. No more no less. If you hash a 800 char passphrase then you maintain most of the entropy of that in the resulting 36 chars. Which is likely to be more.
But that’s not what Sammi described as “support” upthread: “support "infinitely" long passwords without any significant loss of entropy.”¹. That description – i.e. “without loss of entropy” – is what I took issue with, due to the pigeonhole principle.
Personally I don't think there's a practical difference between having 1000 bits of entropy in your password versus 256 bits of entropy, but fair enough.
