Hacker News Reader

Comment by isoskeles | Hacker News Reader

Maximum length makes sense if the hashing algorithm they're using does not go past that length. I think this puts your 1st and 3rd bullet points at odds in some cases, if I understand your point correctly.

I'm not looking this up right now, but I believe bcrypt or some 'version' or 'implementation' (excuse the inaccurate language) of bcrypt limits you to 72 characters. If that limit is not made clear to the user, then they may find it odd when their 73+ character password can have the last N-72 characters changed and still successfully log in. Silent truncation is most likely a result of ignorance on the part of the software developer (I'll admit I did not know about this limit for a long time), whereas maximum length could be the opposite.

More info on this, since I'm no expert: https://security.stackexchange.com/questions/39849/does-bcry...

View on HN

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.

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.

If your backend and frontend engineers are that bad at communicating the api then you probably already have a lot of security problems to begin with.

>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.

> 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.

1. https://news.ycombinator.com/item?id=26866624

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.

Thanks - the sites I'm complaining about typically limit characters somewhere between 18-32 so I suspect it's unrelated to this.

Reply on news.ycombinator.com