Just take the string as bytes and hash it ffs
There’s a special place in hell for those who set an upper limit in password lengths.
I sort of get it. You don’t want to allow the entire work of Shakespeare in the text field, even if your database can handle it.
16 characters is too low. I’d say a good upper limit would be 100, maybe 255 if you’re feeling generous.
The problem is that you (hopefully) hash the passwords, so they all end up with the same length.
At minimum you need to limit the request size to avoid DOS attacks and such. But obviously that would be a much larger limit than anyone would use for a password.
And sure, in theory your hashing browser-side could break if you do that. Depending on how much text the user pastes in. But at that point, it’s no longer your problem but the browser’s. 🦹
The eBay password limit is 256 characters.
They made the mistake of mentioning this when I went to change my password.
Guess how many characters my eBay password has?
I sort of get it. You don’t want to allow the entire work of Shakespeare in the text field, even if your database can handle it.
You don’t store the original text. You store the hash of it. If you SHA512 it, anything that’s ever given in the password field will always be 64Bytes.
The only “legit” reason to restrict input to 16 character is if you’re using an encryption mechanism that just doesn’t support more characters as an input. However, if that’s the case, that’s a site I wouldn’t want to use to begin with if at all possible.
The resulting hash will always be the same size, but you don’t want to have an unlimited upper bound otherwise I’m using a 25GB blueray rip as my password and your service is going to have to calculate the hash of that whenever I login.
Sensible upper bounds are a must to provide a reliable service not open to DDOS exploits.
I’ll admit I kind of typed this without thinking it through. In a secured site, the password would be hashed and salted before storing in the database.
Depending on where you’re doing the hashing, long strings might still slow you down. That being said, from a security standpoint, any gain in entropy by adding characters would be negligible past a certain point. I don’t remember what that number is but it certainly isn’t in the thousands.
Even 255 bytes with 10 million entries is only ~2.6GB of data you need to store, and if you have 10 million users the probably $1 a month extra that would cost is perfectly fine.
I suppose there may be a performance impact too since you have to read more data to check the hash, but servers are so fast now it doesn’t seem like that would be significant unless your backend was poorly made.
Oh and also, “change this every four weeks please.”
Okay then. NEW PASSWORD: pa$$word_Aug24
Yep. Having to have requirements that doesn’t flow with people very well and requiring constant updates, people WILL find shortcuts. In the office, I’ve seen sheets of paper with the password written down, I’ve seen sticky notes, I’ve seen people put them in notepad/word so they could just copy paste.
This is made worse, because you have to go out of your way for a password manager, which means you need to know what that is. And you need a good one because there has been (and I’m going to generalize here) problems with some password managers in the past. And for work, they have to allow a password manager for that to even be an option. Which you then end up with this security theater.
the password cannot contains the same sequences of characters as the old password.
and i have seen this requirement in a service that requires changing it every month for some reasons.
and this is to manage a government digital identity that allows to log it in all governments websites.
the password cannot contains the same sequences of characters as the old password.
That’s a weird way to say “we store your password in plaintext”
Reasonable upper limits are OK. But FFS, the limit should be enough to have a passphrase with 4 or 5 words in it.
Usually 256 bit hash is used. 256 bits is 32 bytes or 32 characters. Of course you are losing some entropy because character set is limited, but 32 characters is beyond reasonable anyway.
The eff passphrase generator has about 2.5 bits of entropy per character (without word separators). Eff recommends 6 word passphrases, and with an avg word length of 7, that’s (only) 79.45 bits of entropy that won’t even fit in the 32 characters. If there wasn’t a password length limit it would be possible to saturate the hash entropy with a 20+ word & 102+ char passphrase.
Just opened a PayPal account and their limit is 20. Plus the only 2fa option is sms 🙃.
I just double checked and I have TOTP enabled for my PayPal account so it should be an option.
I just found this support article of theirs and it says it can only be enabled through their website and not through the app (why?!) so you might be running into that?
Probably people would struggle to scan the QR Code with their smartphone. I think most apps can scan it from a image but obviously this would be unsafe, especially when people sync their screenshot to the cloud.
I can 100% confirm totp exist for PayPal, because I’m using it.
English letters? Really? So basically no a-z, only Æ, Þ, Ƿ, Ð?
Well, yeah. Obviously the roads. I mean, the roads go without saying, don’t they? But apart from the sanitation, the aqueducts, and the roads…
You remind me of my bank about 17 years ago. Everyone had to have a 10-character password, exactly, and it had to include exactly 2 numbers and 1 symbol. I wasn’t very knowledgeable about computers at the time and it already felt dumb.
A few years ago my ISP pushed an update to my router that changed the password requirements, invalidating my passwords. Because I couldn’t enter the old password I also couldn’t change the password. I had to do a factory reset.
Feels odd to check the password requirements on the enter password screen in addition to the new password screen.
Might be checking the old password on the new password screen. Easy programming mistake to make I guess? Apply the same validation to all 3 password fields…
ISP worker here. Our chosen routers default to an 8 digit password, the first 4 are the last 4 of the mac in hex, which anyone can easily see being broadcast by the wifi network. The last 4 are a part of a unique serial number, but its just 0-9. Ultimately, if you try to brute force this default password, you need 10000 tries. It takes a regular GPU 2 minutes with hashcat. It baffles my mind that companies think this is OK.
At that time my bank allowed up to 6 digits as a password. I kid you not, like a card PIN but for online banking login. I believe the whole banking security relies on their backoffices still running on paper.
underlines
I had one of those “fancy” Vodafone routers included with my broadband which had a stupid rule set on choosing the WiFi password. It’s my network, not yours, stupid router. It can be as insecure as I want.
Anyway the rules were enforced by the JavaScript so it was easy to bypass until I got my own router to replace it with.
It’s important to note, that these things are designed for the average user. If you want to change the wifi password, you are by far not an average user. Most users just plugs in and never even think about that, and the number of that kind of users are several order of magnitude higher than the conscious ones. For them it’s much more secure to set a random pw. If you let them select a password they will choose 12345 or password.
If you know what you are doing usually it’s better to buy your own router where you can change everything the way you like.
