I had the opposite issue… how the heck do I need a username over 1000 characters? lol
this post was submitted on 30 May 2025
115 points (98.3% liked)
privacy
4516 readers
99 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:
- community.nicfab.it/c/privacy
founded 3 years ago
MODERATORS
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.
That's some malicious compliance right there! 😂
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!
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.
They shouldn't be using salted hashes since a decade or more. Best is to use a memory hard password hash function like argon
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?
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
And there's no reason a database can't store a very long hash as well. Storage is cheap for this kind of thing.
That's why I only store and compare the first 8 characters.
Why not store the whole thing?
I'm joking of course, but the reason would be the database column is 8 characters.
If only there was a SQL command that could alter an existing table...
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.
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).
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.
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.
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)
load more comments
(9 replies)
ive mostly noticed this on old systems.. where the field length for password was decided by an intern 30 years ago.
load more comments
(5 replies)
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.
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)
load more comments
(7 replies)
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:
(To be clear, this comic's approach to passphrases is sound advice.)
Yeah, I usually limit passwords to 256 characters, because that's way longer than anyone needs and still short enough to not worry about overloading something.
What are you worried about overloading?
Mostly DOS attacks with ridiculously large payloads.
Hashing takes up cpu time
Hashing takes up cpu time
Oh my goodness.
I am very skeptical of this reasoning. If hashing of 256-character passphrases, or even 2560-character passphrases, consumes enough CPU time to risk overloading your system, then I think your are in an infinitesimal niche worthy of a detailed write-up.
If you're worried about that load, just wait until you learn about key derivation functions.
So you were questioning a password limit of 256 chars.
Let's say we do not impose a limit because we're not worried about anything.
We now get hit by a botnet trying to create accounts or login in thousands at the same time.
Say we're using Argon2id. This is obviously subjective to hw and parameters, but let's say 8k characters take 5 seconds of (1) cpu time on your server.
Now multiply this by 1000 attempts a second, and all your hardware does is calculate hashes.
The input limit of Argon2 specifically is much, much higher than that at 2^32-1 bytes, at which point you might as well just take it offline yourself.
If hashing of 256-character passphrases, or even 2560-character passphrases
If we impose no limit, why would the attacker limit themselves to 2560 chars?
Probably so they don't get fired for implementing a DoS vector
view more: next ›