549
NIST proposes barring some of the most nonsensical password rules
(arstechnica.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 26 Sep 2024
549 points (99.3% liked)
Technology
60105 readers
1942 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 2 years ago
MODERATORS
Then you're vulnerable to simple brute force attacks, which if paired with a dumped hash table, can severely cut the time it takes to solve the hash and reveal all passwords.
By any length I meant no maximum length. Obviously you don't want to use a super short password.
"What's your password?"
"The letter A."
Mine is the null string. They'll never guess it!
Some kind of upper bound is usually sensible. You can open a potential DoS vector by accepting anything. The 72 byte bcrypt/scrypt limit is generally sensible, but going for 255 would be fine. There's very little security to be gained at those lengths.
I do 256 so I hopefully never need to update it, but most of my passwords are 20-30 characters or something, and generated by my password manager. I don't care if you choose to write a poem or enter a ton of unicode, I just need a bunch of bytes to hash.