Last week, I tried to register for a service and was really surprised by a password limit of 16 characters. Why on earth yould you impose such strict limits? Never heard of correct horse battery staple?
This is my biggest pet peeve. Password policies are largely mired in inaccurate conventional wisdom, even though we have good guidance docs from NIST on this.
Frustrating poor policy configs aside, this max length is a huge red flag, basically they are admitting that they store your password in plan text and aren’t hashing like they should be.
If a company tells you your password has a maximum length, they are untrustable with anything important.
If a company tells you your password has a maximum length, they are untrustable with anything important.
Lemmy-UI has a password limit of 60 characters. Does that make it untrustworthy?
OWASP recommendation is to allow 64 chars at least:
Maximum password length should be at least 64 characters to allow passphrases (NIST SP800-63B). Note that certain implementations of hashing algorithms may cause long password denial of service.
The lemmy-UI limit is reasonably close and as everything is open source, we can verifiy that it does hash the password before storing it in the database.
There is a github issue, too.
If a company tells you your password has a maximumn length, they are untrustable with anything important.
I would add if they require a short “maximum length.” There’s no reason to allow someone to use the entirety of Moby Dick as their password, so a reasonable limit can be set. That’s not 16 characters, but you probably don’t need to accept more than 1024 anyway.
Sure but if my password is the entire lord of the rings trilogy as a string, hashing that would consume some resources
Of course, but if you’re paying for network and processing costs you might as well cap it at something secure and reasonable. No sense in leaving that unbounded when there’s no benefit over a lengthy cap and there are potentially drawbacks from someone seeing if they can use the entirety of Wikipedia as their password.
I wonder if a lot of it is someone using their personal experience and saying “just a little bigger ought to cover it”
When I used my own passwords, I rarely used more than 12 characters, so that should be enough
All the password generators I’ve used default to about 24 chars, so 30 ought to be enough for anyone
The number of government websites that I’ve encountered with this “limitation.” Even more frustrating when it’s not described upfront in the parameters or just results in an uncaught error that reloads the page with no error message.
bcrypt has a maximum password length of 56 to 72 bytes and while it’s not today’s preferred algo for new stuff, it’s still completely fine and widely used.
also, if they think a strong password is only about types of characters. a dozen words from as many languages and 5+alphabets is just as good!
its to the point I don’t bother remembering my passwords anymore, because this bullshit makes user-memorable-hard-to-machine-guess passwords impossible.
“If a company tells you your password has a maximum length…”
Uhhh no. Not at all. What so ever. Period. Many have a limit for technical reasons because hashing passwords expands their character count greatly. Many websites store their passwords in specific database columns that themselves have a limit that the hashing algorithm quickly expands passwords out to.
If you plan your DB schema with a column limit in mind for fast processing, some limits produce effectively shorter password limits than you might expect. EVERYONE has column limits at least to prevent attacks via huge passwords, so a limit on a password can be a good sign they’re doing things correctly and aren’t going to be DDOS’d via login calls that can easily crush CPUs of nonspecialized servers.
It doesn’t matter the input size, it hashes down to the same length. It does increase the CPU time, but not the storage space. If the hashing is done on the client side (pre-transmission), then the server has no extra cost.
For example, the hash of a Linux ISO isn’t 10 pages long. If you SHA-256 something, it always results in 256 bits of output.
On the other hand, base 64-ing something does get longer as the input grows.
Hashing on the client side is as secure as not hashing at all, an attacker can just send the hashes, since they control the client code.
Can you not simply have a hashing algorithm that results in a fixed length hash?
The hash isn’t at all secure when you do that, but don’t worry too much about it. GP’s thinking about how things work is laughably bad and can’t be buried in enough downvotes.
I had to make an account the other day with the absolute worst password requirements I’ve ever seen:
When I was working on a password system a few years ago, I found some amazingly bad password requirements. One that stuck with me was it couldn’t contain any two digit years (e.g. 08).
I’ll also leave this here: https://dumbpasswordrules.com/sites-list/
That sounds like a rule from The Password Game
I am now even more relieved that the NJ courts have removed me permanently from jury duty, so my chances of interacting with that entire nonsense has gone down. A bit. Just a bit down.
Now I just must try to not be taken to court or take one to court.
This is where hiding inside might help.
The worst is when it either won’t tell you what the character limit is so you have to just keep lowering it and retrying until it finally works, or when the infrastructure for signing up has a different character limit than the infrastructure for logging in, so you can sign up with a long password but can’t actually sign in with it. I once encountered a website that had this issue for both the password AND username so I had to change my password and then contact support to change my username. Absurd.
I used a service that had password validation on the “current password” field when you update your password. My password had stopped being valid due to a change in their password policy, but I couldn’t fix it because the “update password” form kept saying my current password was invalid. I know — you told me to change it!!!
I know a bank with a 12 character max, no symbols password restriction.
Ridiculous
A lot of bank computing is a complete clusterf@#k. Getting even basic changes and bug fixes requires it being signed off on by various regulators and committees. Apparently, 18 months for a 1 line change is normal. This has ended up with layers of new work being frankensteined onto older systems. E.g. Internet banking, for a long time, physically printed checks, via an automated machine, posted them, and then had them read in, via an automated machine. Hence why Internet bank transfers took 2-3 days.
I had issues with my banks truncating my password a while back. It only looked at the first 8 characters.
One of my past banks used to be case-insensitive. They aren’t anymore (as far as I know). Their name starts with Key and ends with Bank.
My bank got busted a few years ago for cheating customers using their coin-counting machines. Literally nickel-and-dimed their own customers. They removed the machines and just threw loose cloth over the empty spaces - an ongoing testament to their shame, if they could feel shame, which they can’t. Out of sheer laziness I’m still with them.
Crazy that there are still banks that use a username and password for login.
In my country all banks just use, instead of a username, the IBAN plus bank card serial number and they give their clients a hardware token that generates one time passwords. The client inserts their bank card into the hardware token then enter their PIN and gets the OTP to login. And when the client wants to make a transfer the bank generates a code that the client has to enter into the hardware token after entering their PIN to generate an OTP which the client uses to confirm the transfer. And if the client has the bank app installed on their phone the bank website generates a QR code which the client can scan with the app and then the client can login with their biometrics. Of course the client has to activate the app with the hardware token first.
This isn’t that much different from a username, password plus 2FA. But this way it takes out the weakness that is the client. This prevents the client from using an easy password or use a username and password that they use everywhere else. Old people don’t write down their password anywhere since there is no password. But they know their PIN by heart since they use it all their life. And it doesn’t rely on apps or SMS for 2FA. So people without a smartphone or even a mobile phone can still use it. Keyloggers are useless since the PIN is entered on the hardware token. Sure a sophisticated con is still possible but thefts like these https://appleinsider.com/articles/23/12/20/how-a-brazen-passcode-thief-used-stolen-iphones-to-rob-2-million where the thieves can drain a bank account if they just steal the phone and phone’s passcode and reset the 2FA are impossible.
The biggest weakness is ofcourse that if someone knows your PIN and obtains your bank card they can enter your bank account online. So the same security measure still applies with this that you should open a savings account at a different bank than your checking account.
A prominent Australian bank has these requirements:
For Internet Banking, your password must be six to eight characters long.
To improve security, it should:
contain both numbers and letters.
include upper and lower-case letters (your password is case sensitive).
8 character max means they’re running it on a mainframe I think, though I don’t know enough about mainframes to know if this is a normal level of bad or really bad
Could be (probably still is) running COBOL. It’s a combination of “if it works and costs money to upgrade, why change” but mostly “if we migrate one thing it will break five other things”.