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?
You must log in or register to comment.
Eons ago, I got an account for using a software on an IBM mainframe. Keep in mind that the machine used masks with fixed-width text fields on the terminal (TN3270, IIRC), even for the login mask. Being security cautious, the first thing I did after login was to change my password. The “change password” mask allowed for passwords of up to 12 characters, which I used freely. I logged out, got back to the login mask - which only allowed for an eight character password…
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 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.
Why not? You’re hashing it anyways, right?
Right?!
Sure but if my password is the entire lord of the rings trilogy as a string, hashing that would consume some resources
I think there are other problems before that 😂
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.
You can also hash it on the client-side, then the server-side network and processing costs are fixed because every password will be transmitted using same number of bytes
You still need to deal with that on the server. The client you build and provide could just truncate the input, but end users can pick their clients so the problem still remains.
The server can just reject any password hash it receives which isn’t exactly hash-sized.
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?
It being open source helps because we can confirm it’s not being mishandled, but it’s generally arbitrary to enforce password max lengths beyond avoiding malicious bandwidth or compute usage in extreme cases.
“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.
Can you not simply have a hashing algorithm that results in a fixed length hash?
That would be all of them, yes.
Just in case someone runs across this and doesn’t notice the downvotes, the parent post is full of inaccuracies and bad assumptions. Don’t base anything on it.
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.
Then you can salt+hash it again on the server.
Hashing is more about obscuring the password if the database gets compromised. I guess they could send 2^256 or 2^512 passwords guesses, but at that point you probably have bigger issues.
Why not just store the first X characters of the hashed password?
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.
Where can I read more about how it’s not secure?
The Wikipedia article is probably a good place to start: https://en.wikipedia.org/wiki/Cryptographic_hash_function
Though I’d say this isn’t something you read directly, but rather understand by going through cryptographic security as a whole.
To keep it short, cryptographic hashes make a few guarantees. A single bit change in the input will cause a drastic change in the output. Due to the birthday problem, the length needs to be double the length of a block cipher key to provide equivalent security. And a few others. When you chop it down, you potentially undermine all the security guarantees that academics worked very hard to analyze.
Even a small change would require going to a lot of work to make sure you didn’t break something. And when you’ve read up on cryptography in general and understand it, this tends to be an automatic reflex.
None of which really matters. GP’s big assumption is that the hash size grows with input size, which is not true. Hash size stays fixed no matter the input.
worst i’ve seen is 8 characters. precisely 8 characters, no more no less… it was for a bank …
The fact that it was a power of 2 makes me suspect lazy coding. That bank didn’t pay its programmers well enough.
Banks don’t have much money for paying people, methinks. They’re famously poor practically non-profits.
No no, not 8 characters, 8 numerical characters!
Whoa whoa whoa, did you use two of the same number in a row? Insecure!
A major US bank that I used to use has case insensitive passwords, found that out one day when I noticed caps lock was on after logging in with no trouble
Makes you wonder if they store the password in plain text, or convert to lower key during your first input so it’s at least hashed. I wouldn’t be surprised if it’s not.
they store the passwords as filenames on a windows system
