this post was submitted on 26 Sep 2024
548 points (99.3% liked)

Technology

59143 readers
5340 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
 

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
[–] [email protected] 20 points 1 month ago (4 children)

Any password length (within reason) and any character should be allowed. It's going to be hashed and only the hash will be stored right? Length and character limits make me suspect it's being stored in plain text.

[–] AliasVortex 24 points 1 month ago* (last edited 1 month ago) (1 children)

I don't know about a min length; setting a lenient lower bound means that any passwords in that space are going to be absolutely brute force-able (and because humans are lazy, there are almost certainly be passwords clustered around the minimum).

I very much agree with the rest though, it's unnerving when sites have a low max length. It almost feels like advertising that passwords aren't being hashed, and if that's the case there's a snowball's chance in hell that they're also salted. Really restrictive character sets also tell me that said site / company either has super old infra or doesn't know how to sanitize strings (or entirely likely both)...

[–] [email protected] 2 points 1 month ago (1 children)

The only justifiable reason I can see to have a length limit is because longer passwords would take more time to process and they don't want to deal with that.

Although it would only be on the order of a couple of extra microseconds and I'm not sure how much difference it would really make. But even on cyber security forums the max password length is 64 characters.

[–] [email protected] 2 points 1 month ago (1 children)

But it really doesn't, unless you're sending megabytes of text or something. Industry standard password algorithms run the hash a lot of times, and your entry will only impact the first iteration.

I usually set mine to 256 characters to prevent DOS attacks, and also so I don't need to update it ever. Most of my passwords are actually around 20-30 characters in length (I pick a random length in the slider on my password manager), because I don't want to be there all day if I ever need to manually enter it (looking at you stupid smart TV...).

[–] subtext 3 points 1 month ago

unless you're sending megabytes of text or something

That’s exactly what someone malicious would do though, either in a single password submission or DOS via the password maximum repeatedly. IMO there is no functional security difference between a 64 and a 256 character password, so the NIST 64 character max is reasonable.

[–] [email protected] 12 points 1 month ago (1 children)

Rules here are 64 as a reasonable maximum. A lot of programmers don't realize that bcrypt and scrypt max at 72 bytes (which may or may not be the same as 72 characters). You can get around it by prehashing, but meh. This is long enough even for a reasonable passphrase scheme.

[–] daddy32 6 points 1 month ago

Minor note: 64 unicode characters is potentially much more than 72 bytes.

[–] [email protected] 4 points 1 month ago (1 children)

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.

[–] [email protected] 7 points 1 month ago (2 children)

By any length I meant no maximum length. Obviously you don't want to use a super short password.

[–] [email protected] 6 points 1 month ago (1 children)
[–] [email protected] 6 points 1 month ago

Mine is the null string. They'll never guess it!

[–] [email protected] 4 points 1 month ago (1 children)

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.

[–] [email protected] 1 points 1 month ago

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.

[–] dual_sport_dork 3 points 1 month ago* (last edited 1 month 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.

[–] [email protected] 1 points 1 month ago* (last edited 1 month 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.