this post was submitted on 17 Jul 2023
271 points (100.0% liked)
Programmer Humor
854 readers
2 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
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