this post was submitted on 18 Aug 2024
847 points (99.0% liked)
Cybersecurity - Memes
1964 readers
2 users here now
Only the hottest memes in Cybersecurity
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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..."
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.
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.
It's more about when a database gets leaked. They then don't even have to put in the effort of trying to match hashes to passwords. And that's what hashing a password protects against, when done correctly.