this post was submitted on 26 Sep 2024
11 points (100.0% liked)
Technology
58513 readers
4195 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Reworded rules for clarity:
I was expecting idiotic rules screaming "bureaucratic muppets don't know what they're legislating on", but instead what I'm seeing is surprisingly sane and sensible.
NIST generally knows what they're doing. Want to overwrite a hard drive securely? NIST 800-88 has you covered. Need a competition for a new block cipher? NIST ran that and AES came out of it. Same for a new hash with SHA3.
For now, at least. Could change after Inauguration Day.
Didn’t know about sha3.
I think if you do allow 8 character passwords the only stipulation is that you check it against known compromised password lists. Again, pretty reasonable.
That stipulation goes rather close to #5, even not being a composition rule.
I think that a better approach is to follow the recommended min length (15 chars), unless there are good reasons to lower it and you're reasonably sure that your delay between failed password attempts works flawlessly.
It's crazy that they didn't include all the "should" items in that list. If you read the entire section, there's a critical element that's missing in the list, which is that new passwords should be checked against blocklists. Otherwise, if you combine 1, 5, and 6, you end up with people using "password" as their password, and keeping that forever. Really, really poor organization on their part. I'm already fighting this at work.
Only issue I see is that the 8 chars required is very short and easy to brute force. You would hope that people would go for the recommended instead, but doubt it.
I hate that anyone has to be told not to truncate passwords. Like even if you haven't had any training at all, you'd have to be advanced stupid to even come up with that idea in the first place.
Microsoft used to do that. I made a password in the late 90's for a we service and I found out that it truncated my password when they made it after it warned my my password was too long when I tried to log in. It truncated at 16 characters.
Can you elaborate further? Why would someone want to truncate passwords to begin with?
To save a few megabytes of text in a database somewhere. Likely the same database that gets hacked.
It needed to be said. Because some password system architects have been just that stupid.
Edit: Fear of other's stupidity is the mind killer. I will face my fear. My fear will wash over me, and when it has passed, only I will remain. Or I'll be dead in a car accident caused by an AI driver.
I've seen sites truncate when setting, but not on checking. So you set a password on a site with no stated limit, go to use said password, and get locked out. It's infuriating
Sounds like my bank.
Banks usually have the absolute worst password policies. It's typically because their backend is some crusty mainframe from the 80s that limits inputs to something absurdly insecure by today's standards and they've kicked the upgrade can down the road for so long now that it's a staggeringly monumental task to rewrite it all. Thankfully most of them have upgraded at this point, but every now and then you still find one that's got ridiculous limits like a maximum password length of 8 and only alphanumeric characters (with no 2FA obviously).
Years back, I had that happen on PayPal of all websites. Their account creation and reset pages silently and automatically truncated my password to 16 chars or something before hashing, but the actual login page didn't, so the password didn't work at all unless I backspaced it to the character limit. I forgot how I even found that out but it was a very frustrating few hours.
Another ridiculous policy I've seen (many years ago) is logging in too fast. I used to get locked out of my banks website all the time and I used autotype with KeePass so I was baffled when it wouldn't get accepted. Eventually I had a thought to slow down the typing mechanism and suddenly I didn't get locked out anymore.
Hmm. I wonder about this one. Different ways to encode the same character. Different ways to calculate the length. No obvious max byte size.
Who cares? It's going to be hashed anyway. If the same user can generate the same input, it will result in the same hash. If another user can't generate the same input, well, that's really rather the point. And I can't think of a single backend, language, or framework that doesn't treat a single Unicode character as one character. Byte length of the character is irrelevant as long as you're not doing something ridiculous like intentionally parsing your input in binary and blithely assuming that every character must be 8 bits in length.
It matters for bcrypt/scrypt. They have a 72 byte limit. Not characters, bytes.
That said, I also think it doesn't matter much. Reasonable length passphrases that could be covered by the old Latin-1 charset can easily fit in that. If you're talking about KJC languages, then each character is actually a whole word, and you're packing a lot of entropy into one character. 72 bytes is already beyond what's needed for security; it's diminishing returns at that point.
NIST are bureaucrats sure, but bureaucrats with lots and lots of practical experience.
This is a big one. Especially in corporate environments where most of the users are, shall we say, not tech savvy. Forcing people to comply with byzantine incomprehensible password composition rules plus incessantly insisting that they change their password every 7/14/30 days to a new inscrutable string that looks like somebody sneezed in punctuation marks accomplishes nothing other than enticing everyone to just write their password down on a Post-It and stick it to their monitor or under their keyboard.
Remember: Users do not care about passwords. From the perspective of anyone who isn't a programmer or a security expert, passwords are just yet another exasperating roadblock some nerd keeps putting in front of them that is preventing them from doing whatever it is they were actually trying to do.
Everyone I've spoken to who has a password change rule just changes one character from their previous password. It does NOTHING.
That works great until some dickhole implements the old, "New password cannot contain any sequence from your previous (5) passwords."
This also of course necessitates storing (multiple successive!) passwords in plain text or with a reversible cipher, which is another stupid move. You'd think we'd have gotten all of this out of our collective system as a society by now, and yet I still see it all the time.
All of these schemes are just security theater, and actively make the system in question less secure while accomplishing nothing other than berating and frustrating its users.
HA, I hope you're joking. Surely nobody's actually done that, right? ....Riiiight?
This also leads to stupid rules like you can’t change your password more than once a day, to prevent someone from changing their password 5 times and then changing it back to what it was before.
"I just increment the number at the end" is a phrase I've heard so many times