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