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 are viewing a single thread.
View all comments
134 points

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.

permalink
report
reply
86 points

Oh I had the same thought. Whoever limits password length probably has many other shitty security practices.

permalink
report
parent
reply
31 points

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?

permalink
report
parent
reply
57 points

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.

permalink
report
parent
reply
14 points

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.

permalink
report
parent
reply
20 points

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.

permalink
report
parent
reply
5 points

Why not? You’re hashing it anyways, right?

Right?!

permalink
report
parent
reply
12 points

Sure but if my password is the entire lord of the rings trilogy as a string, hashing that would consume some resources

permalink
report
parent
reply
5 points

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.

permalink
report
parent
reply
2 points

Bcrypt and scrypt functionally truncate it to 72 chars.

There’s bandwidth and ram reasons to put some kind of upper limit. 1024 is already kinda silly.

permalink
report
parent
reply
1 point

you probably don’t need to accept more than 1024 anyway.

OWASP recommends allowing at least 64 characters. That would cover all of my passphrases, including the ones that are entire sentences

permalink
report
parent
reply
1 point

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

permalink
report
parent
reply
13 points

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.

permalink
report
parent
reply
2 points
*

Or accepts and silently truncates it 🤬

permalink
report
parent
reply
10 points

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.

permalink
report
parent
reply
2 points

Wait, really? I always thought bcrypt was just a general-purpose hash algorithm, never realized that it had an upper data size limit like that.

permalink
report
parent
reply
2 points

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.

permalink
report
parent
reply
1 point

I am now very concerned about a certain medical implant device company

permalink
report
parent
reply
0 points

True!

permalink
report
parent
reply
-8 points
*

“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.

permalink
report
parent
reply
15 points

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.

permalink
report
parent
reply
3 points

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.

permalink
report
parent
reply
5 points

Can you not simply have a hashing algorithm that results in a fixed length hash?

permalink
report
parent
reply
7 points

That would be all of them, yes.

permalink
report
parent
reply
4 points

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.

permalink
report
parent
reply
0 points

Why not just store the first X characters of the hashed password?

permalink
report
parent
reply
1 point
*

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.

permalink
report
parent
reply

Cybersecurity - Memes

!cybersecuritymemes@lemmy.world

Create post

Only the hottest memes in Cybersecurity

Community stats

  • 2.4K

    Monthly active users

  • 79

    Posts

  • 1.2K

    Comments