Was testing things and ran into autofill errors with KeePassXC. Looks like the Firefox plugin manages to pass the full length of the password, even if the input field is limited to a lower number of chars. Manually pasting the password truncates it, though.
You must log in or # to comment.
Good to know. Thanks!
Considering hash functions used for passwords operate in a range of 32 to 64 bytes, that’s really not a problem. Go above that length, and you’re not ultimately improving your password collision resistance due to pigeonhole principle.
There are caveats. For example, if the only source of feeding the colliding passwords to the system is an endpoint that filters for human readable inputs, then that could double (well, spread) the effective collision search space size. Which is not really a factor on your 480 bits password length.
PS: Newer password hashing algorithms like argon2 can scale into gods defying territory, but in practice they also tend to stay below 128 bytes. Those hashes need to be stored, calculated, and compared - all of which are DoS vectors.
Pidgeonhole principle for those interested. Thank you, I’ve learnt something today!
Those hashes need to be stored, calculated, and compared - all of which are DoS vectors.
Fair point. But at least a visible range next to the form would be such a massive improvement already.
Definitely. I’d say the limit should also be calculated over a useful inputs space, which is likely larger than 60 symbols. A good chunk of byte sequences that hash algorithm could accept are nearly guaranteed to never be submitted by a legitimate user.
Depending on an encoding and an alphabet the password manager or user themselves use, up to half of possible bit sequences are impossible to achieve. E.g. 10000001 is not a valid one-character string in UTF-8. And no upper byte in UTF-8 can’t start with 0. So it’s easy to get locked to 7 bits of variability on every byte.
Which would mean that 60 symbols input is not 2^480 variable bytes, but 2^420. That translates into an effective length of about 52 characters. Still a lot and above what’s considered vulnerable, but a few more restrictions or overeager optimizations, and suddenly the problem is shrunk to a space that a bitcoin farm can manage.
In other words, security is a fascinating topic.
PS: “up to half” is definitely optimistic, by the way. I’m definitely unlikely to ever produce a password that has a byte starting with 0 and two follow up bytes starting with 1s. I won’t even know how to type them, and I like my passwords typable.
This is fascinating :)
Just to double check - did you mean bits rather than bytes?
Just reread my wall of text, and I think bits and bytes are in the right places. I do have a tendency to be blind to my own typos, however, so there’s that ._.
I had a problem once logging in at my insurance website. A simple copy paste from KeePass, but it said wrong password, it didn’t make sense to me. Until I tried to only copy 8 characters into the PW field and it worked :/
But 60 seems reasonable long.
It is reasonable, but I can’t shake off this dislike towards such arbitrary feeling limits. I know some algorithms have issues with certain lengths, but why bother preventing me from logging in? Truncate it at the hashing step and let me move on with my life. Or at least state it beforehand.
The worst offenders are the ones who allow signing up without a limit but the login form starts enforcing it and you can never pass through it.
This is one of the most annoying things I regularly encounter in life, and it’s reassuring that I’m not the only one so irritated by it.
THANK YOU
In this same vein, I used to work as tech support for a bank that had a key fob token rotator for 2fa. The implementation was you put the token in the password field after the password.
The website did not tell you it truncated after 8 characters. There was also no real indicator that the actual activation of the token was the first attempted use after it was received.
Many customers had passwords longer than 8 characters (or so they thought) and tokens that never activated because the longer password resulted in the token being truncated as well.
