this post was submitted on 30 May 2025
114 points (98.3% liked)

privacy

4345 readers
4 users here now

Big tech and governments are monitoring and recording your eating activities. c/Privacy provides tips and tricks to protect your privacy against global surveillance.

Partners:

founded 3 years ago
MODERATORS
 

It's infuriating to create a "strong password" with letters, numbers, upper and lowercase, symbols, and non-repeating text... but it has to be only 8 to 16 characters long.

That's not a "strong" password, random characters or not.

Is there a limitation that somehow prevents these sites from allowing more than 16 characters?

I'm talking government websites, not just forums. It seems crazy to me.

top 50 comments
sorted by: hot top controversial new old
[–] Retro_unlimited@lemmy.world 23 points 3 days ago (1 children)

I had the opposite issue… how the heck do I need a username over 1000 characters? lol

[–] hightrix@lemmy.world 17 points 3 days ago (1 children)

Because the requirement was to allow user names, the dev asked what the limit should be, the PM said, “I don’t care, make it 1000”, and so the dev did it.

Source: I’ve been working in software far too fucking long.

[–] Showroom7561@lemmy.ca 5 points 3 days ago

That's some malicious compliance right there! 😂

[–] Creat@discuss.tchncs.de 71 points 4 days ago (3 children)

It's a massive red flag. It implies that they are actually storing the password instead of a (preferably salted) hash and that they have no idea what good security practices are. Storing a hash leads to same size strings, no matter the length on the password.

And there's no reason a database can't store a very long hash as well. Storage is cheap for this kind of thing.

[–] sik0fewl@lemmy.ca 10 points 4 days ago (3 children)

That's why I only store and compare the first 8 characters.

load more comments (3 replies)
[–] jagged_circle@feddit.nl 3 points 3 days ago (1 children)

They shouldn't be using salted hashes since a decade or more. Best is to use a memory hard password hash function like argon

[–] brisk@aussie.zone 2 points 3 days ago (1 children)

Can you expand on this? My experience with Argon is looking up a Wikipedia page in response to this comment, but it looks like it uses a salt as an input?

[–] jagged_circle@feddit.nl 1 points 2 days ago* (last edited 2 days ago)

Its a password specific function. Its also memory hard.

As oposed to generation a salt and passing that with the password through sha256 or something, which is bad practice

[–] phoenixz@lemmy.ca 15 points 3 days ago

Irá usually bad backend design, bad frontend design, all made by people who are only vaguely aware of security, and how it works.

It's the same bunch that brought us "change your password every two weeks" and other insane anti security designs. They make it worse without even realizing it.

Do hope that your passwords aren't stored in plain text!

[–] Thorry84@feddit.nl 51 points 4 days ago (3 children)

There are valid reasons to limit password length. For example when a hashing function is used that requires a lot of processing power and the amount of power required to calculate the hash is related to the length. In that (very common) case, a denial of service attack vector is exposed. By simply spamming insane long passwords into a login form for example, the servers calculating the hash get easily overloaded. Even with rate limiting, only a small number of attacking nodes can be used to pull down a site.

So a maximum number of characters for a password is a valid thing to do. HOWEVER the maximum length for this purpose is usually set at something like 2048 or 4096 characters.

There is no excuse for a max password length of 16, that's just terrible.

[–] Showroom7561@lemmy.ca 12 points 4 days ago (2 children)

There is no excuse for a max password length of 16, that’s just terrible.

I get your point above, and the reason I hate short passwords is that I use passphrases. They are not only easier to type in, but long passphrases of 4+ words (plus a few extra characters and a number) are considerably more secure than the "best" 16-character password made up of random characters.

Per your problem above, is this why some sites send you a 2FA code before asking for your password? To avoid that potential DOS attack?

load more comments (2 replies)
[–] some_guy 10 points 4 days ago (2 children)

Sixteen is the minimum where I work. We upped it at the end of last year. Fortunately, we also fixed our password policy to expire annually. It used to be every three months, which leads to recycling.

[–] jagged_circle@feddit.nl 8 points 3 days ago (1 children)

NIST recommended to never have passwords expire since like 3 decades. You gotta get rid of that. It makes your org less secure.

Probably best to just fire whoever set that up. They're clueless

[–] filcuk@lemmy.zip 3 points 3 days ago

These policies typically come from top management. They'd have to fire themselves.

[–] sugarfoot00@lemmy.ca 7 points 4 days ago (5 children)

There's always recycling. Or changing that final character from a 1 to a 2, etc. The human brain just cant handle the complexity otherwise.

load more comments (5 replies)

You could put a timeout on the hash function so that it can't be abused that way, but then... why not just make a limit so it can't anyway.

[–] wesker 55 points 4 days ago (1 children)

It's informative. It informs you that you shouldn't use the site, if possible. Because it's also suggestive of poor security practices in general.

[–] MelodiousFunk@slrpnk.net 11 points 4 days ago* (last edited 4 days ago) (1 children)

Yeah, imagine my shock and disappointment when encountering such limitations signing up for credit monitoring (by one of the big 3). It's not enough that my employer has a breach, no. But also finding out that one of the big players has some ridiculous 12 character alphanumeric password restriction. Absolute dogshit.

A random 12-character password should take years to crack. But they're probably also storing it as plaintext, so no need to crack, just breach the DB (which is probably also insecure).

[–] originalucifer@moist.catsweat.com 25 points 4 days ago (1 children)

ive mostly noticed this on old systems.. where the field length for password was decided by an intern 30 years ago.

[–] shalafi@lemmy.world 6 points 4 days ago (4 children)

This is it right here. The new system has to talk to the old database which has a character limit for that field. Untold amounts of money and effort would be required to update the back end.

load more comments (4 replies)
[–] who@feddit.org 15 points 4 days ago* (last edited 4 days ago) (7 children)

No, there is no valid reason to limit web passwords to lengths as short as 8 or 16 characters. If someone has built such a system with a technical limit that short, then what they have built is (from a security perspective) garbage.

Thankfully, NIST finally dropped their terrible password guidelines of the past in favor of sensible ones. Perhaps this will lead to fewer bad decisions being made in web development circles.

A few relevant sections:

https://pages.nist.gov/800-63-4/sp800-63b.html#usability-considerations-by-authenticator-type

https://pages.nist.gov/800-63-4/sp800-63b.html#length

https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver

Obligatory xkcd:

https://xkcd.com/936/

(To be clear, this comic's approach to passphrases is sound advice.)

load more comments (7 replies)
[–] UnpopularCrow@lemmy.world 15 points 4 days ago (2 children)

It’s usually shoddy (or intended?) coding that only allows a 16 byte length for the password. One character equals one byte of memory so my guess is they only allocated 16 bytes of space for the password. The irony is NIST 2025 recommendations argue for AT LEAST 15 characters for passwords.

[–] tleb@lemmy.ca 21 points 4 days ago (1 children)

One character equals one byte of memory so my guess is they only allocated 16 bytes of space for the password.

This is true for storing text in general but passwords aren't supposed to be stored as text, they should be hashed. The size of the hash will depend on the hashing algorithm. In other words, if there's a database limitation for the size of a password, it probably means they're storing the password plaintext 💀

More likely than not it's just some poorly designed validation

load more comments (1 replies)
[–] DocMcStuffin@lemmy.world 6 points 4 days ago (1 children)

What's funny is a character isn't necessarily a byte now. It could be 1, 2, 3, or 4 bytes. Or only 2 or 4 bytes if we include utf-16 and 32. Character encodings are fun!

[–] elvith@feddit.org 5 points 4 days ago* (last edited 4 days ago) (5 children)

Guess how many systems 'with full unicode support' are broken by using emojis in your username or password...

load more comments (5 replies)
[–] ICastFist@programming.dev 8 points 4 days ago

Probably running on code from before 2000.

[–] Subscript5676@lemmy.ca 7 points 4 days ago

There’s no good reason today and in the future, period.

There are “experts” who still claim these, but they are based on a very dated recommendation from at least 15 - 20 years ago at this point. To some, such non-sensical requirements (by the fact that we should be storing passwords as hashes today) have become doctrine, rather than any fact based in reality.

And some users have been conditioned into thinking that these are good security practices as well, because governments and banks still make use of them, and these are the very organizations that should be the best-in-class when it comes to security. Some of these users become CEOs or product designers with more say than their IT and security experts in the company. The rest is history from there.

[–] chickenf622@sh.itjust.works 9 points 4 days ago (1 children)

Yeah that's cause they're using ancient systems that probably store the password in plaintext. If you absolutely must use it make sure that password is only used on that specific site. I would strongly recommend looking for other ways before you do though.

[–] Showroom7561@lemmy.ca 8 points 4 days ago (2 children)

If you absolutely must use it make sure that password is only used on that specific site. I would strongly recommend looking for other ways before you do though.

Not only did I use a completely unique and random password, but all the "security questions" (they asked for quite a few), were just random words for things like "Your pet's name".

In addition to the shitty password requirement, 2FA is also done by phone or text. Like, come on!

[–] drspod@lemmy.ml 6 points 4 days ago

You should treat security questions like passwords and use strong alphanumeric passwords as the answers. Just make sure to store them in your password manager in such a way that you can remember which one goes with which question!

load more comments (1 replies)
[–] homesweethomeMrL@lemmy.world 6 points 4 days ago (1 children)

It means it’s stored unencrypted.

[–] drspod@lemmy.ml 10 points 4 days ago (1 children)

You don't want your password to be encrypted, you want it to be hashed.

[–] homesweethomeMrL@lemmy.world 5 points 4 days ago (1 children)

I was going to say hashing is a kind of encryption but I can tell you're an engineer, so I'll simply link my feeble cite and go back to my corner quietly.

[–] drspod@lemmy.ml 10 points 4 days ago (1 children)

The fundamental difference is that hash functions are designed to be irreversible (one-way functions), whereas encryption is designed to be reversible (where the inverse operation is called "decryption").

load more comments (1 replies)
[–] witheyeandclaw 6 points 4 days ago (10 children)

Piggybacking on this because i do IT for a major US bank that requires passwords to be a set number of characters for its employees. I don't want to be specific, but it's in the range OP posted of 8-16.

load more comments (10 replies)
[–] DocMcStuffin@lemmy.world 6 points 4 days ago

There was one point in time when Intel's website only allowed up to 14 characters and disallowed certain special characters. If I had to guess why, fear of inadequate error checking and fear of sql injection.

load more comments
view more: next ›