Infuriating fact: if a service has maximum password length limits (lower than 1000 characters), they’re reversibly storing your password and if they’re that lazy it’s probably plain text
That sounds incredibly unlikely. I would be good money that 99% of password length limits are not based on concrete limits. Things like “100 should be enough 🤷” must be way more common.
I doubt 1% of programmers are away of their hashes block size. It is also probably irrelevant since after the first round everything is fixed size anyways.
Fun fact: Lemmy instances cap at 60. they’re not storing reversibly, they’re just using bcrypt and rather than pre-hashing the pw before bcrypt like most bcrypt users do, they just truncate to 60.
Not necessarily. There is another reason. Password hash functions like PBKDF2 are, by design, slow. Allowing extremely long passwords while using such a hash function creates a denial-of-service vulnerability.
Assuming the hash function takes proportionally more time to compute the hash of a longer password, of course. I believe they do, but I’m not certain.
Infuriating fact: if a service has maximum password length limits (lower than 1000 characters), they’re reversibly storing your password and if they’re that lazy it’s probably plain text
reversibly?
In the least bad case, they encrypt the password instead of hashing it, making it possible to decrypt the password.
In the most common case, they store the password in plaintext, so there isn’t even any encryption to be reversed.
They may just base their limit on one or a few block sizes of the hash function.
That sounds incredibly unlikely. I would be good money that 99% of password length limits are not based on concrete limits. Things like “100 should be enough 🤷” must be way more common.
I doubt 1% of programmers are away of their hashes block size. It is also probably irrelevant since after the first round everything is fixed size anyways.
Fun fact: Lemmy instances cap at 60. they’re not storing reversibly, they’re just using bcrypt and rather than pre-hashing the pw before bcrypt like most bcrypt users do, they just truncate to 60.
60 makes sense, 14 does not
Not necessarily. There is another reason. Password hash functions like PBKDF2 are, by design, slow. Allowing extremely long passwords while using such a hash function creates a denial-of-service vulnerability.
Assuming the hash function takes proportionally more time to compute the hash of a longer password, of course. I believe they do, but I’m not certain.