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.
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)…
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.
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…).
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.
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.
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.
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.
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.
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.
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.
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)…
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.
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…).
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.
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.
Minor note: 64 unicode characters is potentially much more than 72 bytes.
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.
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.
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.