Technology

59724 readers

3878 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

549

NIST proposes barring some of the most nonsensical password rules (arstechnica.com)

submitted 2 months ago by Amicitas@lemmy.world to c/technology@lemmy.world

179 comments fedilink hide all child comments

Here is the text of the NIST sp800-63b Digital Identity Guidelines.

you are viewing a single comment's thread
view the rest of the comments

[–] dual_sport_dork@lemmy.world 3 points 2 months ago* (last edited 2 months ago) (1 children)

You should probably have some safeguard to prevent jokers from uploading 14.2 gigabytes of absolute nonsense into your system's password field just to see if they can make it crash. But I think limiting it to, like, 8 kB ought to be quite lenient for anything with a modern internet connection.

As others have noticed, various hashing functions have an upperbound input length limit anyway. But I don't see any pressing reason to limit your field length to exactly that, even if only not to reveal anything about what you might be feeding that value into behind the scenes.

[–] sugar_in_your_tea@sh.itjust.works 1 points 2 months ago* (last edited 2 months ago)

I usually do 256 characters. That's long enough that most password managers top out anyway (mine tops out at 128), and it shouldn't ever present a DOS risk. Anything much beyond that and you'll go beyond the hash length.