So I just went through something similar with a security team, they were concerned that any data should have limits even if transiently used because at some point that means the application stack is holding that much in memory at some point. Username and password being fields you can force into the application stack memory without authentication. So potentially significantly more expensive than the trivial examples given of syn and pings. Arbitrary eaders (and payloads) could be as painful, but like passwords those frequently have limits and immediately reject if the incoming request hits a threshold. In fact a threshold to limit overall request size might have suggested a limited budget for the portion that would carry a payed.
24 characters is enough to hold a rather satisfactorily hardened but human memorable passphrase. They mentioned use of a password manager, in which case 24 characters would be more entropy than a 144 bit key. Even if you had the properly cryptid and salted password database for offline attack, it would still be impossibly easier to just crack the AES key of a session, which is generally considered impossible enough to ignore.
As to the point about they could just limit requests instead of directing a smaller password, well it would certainly suck of they allowed a huge password that would be blocked anyway, so it makes sense to warn up front.
pennomi@lemmy.world 1 week ago
Not DDOS, DOS. You can often crash an unprepared server with one request by telling it to hash more data than it has memory for. See this blog post for a well-known web framework. Let’s say I just sent it a 10GB password, it still has to process that data whether or not the hash eventually shortens to the database field length.
jj4211@lemmy.world 1 week ago
Though it could also amplify DDOS. Allowing 72 character passwords lets a DDOS be three times rougher despite being a seemingly modest limit for a single request.
If a password/passphrase is 24 characters, then any further characters have no incremental practical security value. The only sorts of secrets that demand more entropy than that are algorithms that can’t just use arbitrary values (e.g RSA keys are big because they can’t be just any value).
rumba@lemmy.zip 1 week ago
Just another in a long list of decisions Django made that makes me dislike it.
Let the client hash the password to reduce it. then enforce the hash length as the password length. It’s transparent to the user and doesn’t look like a pile of bad ideas.