But you forgot the rule where it couldn’t be more than 12 characters long, so you didn’t try the correct variation until the validation error for the password reset told you what the rules are.
the rule where it couldn’t be more than 12 characters long
This is the one I don’t get. Sure you don’t want people putting in an infinitely long password, but I like to have my passwords at around 15 characters. Why are you forcing me to make a less secure password?
Only reason I can think of is storage but even at a massive scale, this is text, paying for that storage would cost as much as a rounding error.
It’s even worse. If done correctly, the length of the password does not affect the size of the stored value. Because if you’re doing it right, you only save the hash of the password. And the length of the hash is fixed.
There’s a type of attack where you put absurdly large inputs into fields that perform expensive calculations, like password hashing… So imagine 100 computers spamming the login form with the whole Bee Movie script 10x per second (which would be a pretty small attack)… Cheap to send, expensive to process. As others mention, the storage should be cheap, because the hashed version of the password is all the same length.
So it makes sense for apps to have SOME upper limit… But it should be like 64 or 100 or 128 or 500 or something. 12 or 16 or 20 is just obnoxious.
But they don’t (shouldn’t) store the actual password. They store a hash of the password, which is the same length regardless of length of the actual password.
I’m happy to comply with your complexity requirements, but don’t tell me about each one only when I’ve failed to meet it. That’s really past the bar of shitty design into the realm of asshole design.
I had an account with a bank that got bought. Always used the app, which worked fine, but I needed some document I could only get from the website. Go to log in and it gives me all sorts of weird errors. Support made me reset my password, all that stuff. I figured it out. Old bank would let you log in with email or username. New bank only let you log in with username, except it had dropped old bank’s username and put the email in the username field in their database. The website scrubbed emails from that field, and so it submitted a null username. The app didn’t l, so it let me log in. Weirdest issue I’ve ever had with a service and actually figured it out.
Using android banking app, phone broke, new phone with same app flagged and froze my whole account. I had no access to my money and had to physically go to the bank to get it all unlocked, they couldn’t do it over the phone. Only had $20 in my wallet and thankfully my cab driver took me there even though the fare was more. Not a fun day.
I’m not a security expert, so I’m sure someone can correct me, but it is my understanding that all the nonsense of adding numbers and special characters does nothing to increase security. Longer passwords increase security, even if they are all lowercase letters.
So, “PaS$w3rD@” is a much less secure password than “sallyandbillywenttothestoreforsoda”
But you forgot the rule where it couldn’t be more than 12 characters long, so you didn’t try the correct variation until the validation error for the password reset told you what the rules are.
This is the one I don’t get. Sure you don’t want people putting in an infinitely long password, but I like to have my passwords at around 15 characters. Why are you forcing me to make a less secure password?
Only reason I can think of is storage but even at a massive scale, this is text, paying for that storage would cost as much as a rounding error.
My password generator is set to 24 characters. 12 or 15 seems a bit short.
It’s even worse. If done correctly, the length of the password does not affect the size of the stored value. Because if you’re doing it right, you only save the hash of the password. And the length of the hash is fixed.
There’s a type of attack where you put absurdly large inputs into fields that perform expensive calculations, like password hashing… So imagine 100 computers spamming the login form with the whole Bee Movie script 10x per second (which would be a pretty small attack)… Cheap to send, expensive to process. As others mention, the storage should be cheap, because the hashed version of the password is all the same length.
So it makes sense for apps to have SOME upper limit… But it should be like 64 or 100 or 128 or 500 or something. 12 or 16 or 20 is just obnoxious.
But they don’t (shouldn’t) store the actual password. They store a hash of the password, which is the same length regardless of length of the actual password.
THIS is the one that makes me the angriest.
I’m happy to comply with your complexity requirements, but don’t tell me about each one only when I’ve failed to meet it. That’s really past the bar of shitty design into the realm of asshole design.
And it’s so weird that almost everyone seems to do it that way. I can’t think of a reason other than complacency of a non-golden path interaction.
I had an account with a bank that got bought. Always used the app, which worked fine, but I needed some document I could only get from the website. Go to log in and it gives me all sorts of weird errors. Support made me reset my password, all that stuff. I figured it out. Old bank would let you log in with email or username. New bank only let you log in with username, except it had dropped old bank’s username and put the email in the username field in their database. The website scrubbed emails from that field, and so it submitted a null username. The app didn’t l, so it let me log in. Weirdest issue I’ve ever had with a service and actually figured it out.
Using android banking app, phone broke, new phone with same app flagged and froze my whole account. I had no access to my money and had to physically go to the bank to get it all unlocked, they couldn’t do it over the phone. Only had $20 in my wallet and thankfully my cab driver took me there even though the fare was more. Not a fun day.
Whew yeah that’s a shitty one too. Good job working it out!
I’m not a security expert, so I’m sure someone can correct me, but it is my understanding that all the nonsense of adding numbers and special characters does nothing to increase security. Longer passwords increase security, even if they are all lowercase letters.
So, “PaS$w3rD@” is a much less secure password than “sallyandbillywenttothestoreforsoda”
You are exactly right and here is a comic that explains it. But nearly 0 websites have caught on to this.
https://xkcd.com/936/?correct=horse&battery=staple
That’s 59 and 159 bits of entropy, respectively according to some random online password entropy calculator I found.
Even better, just type out the whole sentence fully. Why disallow spaces?
“Sally and Billy went to the store for soda”. 274 bits.