In password security, the longer the better. With a password manager, using more than 24 characters is simple. Unless, of course, the secure password is not accepted due to its length. (In this case, through STOVE.)
Possibly indicating cleartext storage of a limited field (which is an absolute no-go), or suboptimal or lacking security practices.
I got a login on an IBM system. I logged in and moved to the change password mask. Changed my password to something filling out the 12 character new password field. Logged out, and got the login mask again. With an eight character password field.
when you varchar(24) and forget about the hash
Hey at least it told you there maximum length, i signed up paramount+ last night and it only said 42 characters was too long.
Maybe they allow more characters during the day /s
too many people ITT not decrying passwords for certified session security keys on the 21st post quantum era.
smh.In my opinion, an acceptable password length should be
Linln(alphabetSize^L)/ln(2) = (B bits of entropy). For a Bech32 character set (since it excludes ambiguous characters),alphabetSize = 32. A good password should have been 96 and 256 bits of entropy, with 128 bits being my personal preference. This meansL = (B)*ln(2)/ln(alphabetSize) = 128*ln(2)/ln(32) = 25.6 = 26 characters.That’s… pretty close to what OP said they were restricted to, so maybe the person who set the 24 character restriction used a similar methodology.
26 characters? Perfect!
abcdefghijklmnopqrstuvwxyz it is! And I’ll use it for everything!
That would suck to enter. Much better to do qwertyuiopasdfhhjklzxcvbnm
Or if you are cool: pyfgcrlaoeuidhnnsjkxbmwvq
is that Dvorak I spy?
That’s the combination to my luggage!
I also hate these kind of websites.
Used to run into this more. Some legacy systems imposed password limits that seem archaic by modern standards. The authentication system was just supporting systems from before newer standards were created.
I think some of those compatibility layers outlived the systems they needed to be compatible with. The people that knew the system retired ages ago and the documentation was lost 3 or 4 “documentation system” changes ago.
Anyway, those have no place on the modern web.
You think that’s infuriating? Imagine having an ISP that wants you to pick a password of max 8 characters.
That was the insurance corp my career came bundled with for a decade until recently.
Sunlife. Finally very slowly replacing their garbage old website.
I’ll do you one better. The target redcard credit card doesn’t allow non-standard special chars, max I think it was 12 chars and gets pissy at using known SQL special chars. If it wasn’t for the fact it required a credit check prior to getting to that screen I would have ran so hard.
What’s even more annoying is their password field says that it does support that, but if you try via the mobile app it errors out
Time to choose a new ISP!
Ah yes, I will just go to another ISP. Wait, there’s only one.
In the US you can pull up the FCC broadband tracker to see what companies offer service
Sure but that doesn’t change the lack of competition. For my address, I have two non wireless providers, and one of them is copper only and capped at 50 down. So not a lot of choice if an ISP is screwing you.
That really sucks
I feel like it is cases like that were community run infrastructure can really help. It provides decent service and puts pressure on the local ISP to do better.
My bank does this 💀
There was a game launcher for a popular game that required a minimum of 8 characters but only used the first 8 characters and it wasn’t case sensitive. So something like PassWord12345!? could be entered when changing the password, but you could sign in with any of the following:
- password1234
- PassWord123499(#$%
- Password12345!?
- passWord12345!
- pASSword12345?!
- PassWord123499(#$%
- password
I haven’t logged in for years so I’m not sure if it is still working that way.
deleted by creator
Utf8 isn’t ASCII. It takes up more space.
No, it does not take up more space for ASCII characters.
If you want a source, Wikipedia
the first 128 characters of Unicode, which correspond one-to-one with ASCII, are encoded using a single byte with the same binary value as ASCII
Good to know
I was just speculating
deleted by creator
There should be a limit to prevent DoS attacks but really it should be like 1M characters or something.
No, there should be no limit. The password should be salted and hashed stored on the server side they should be uniformly like 256 or 512 characters behind the scenes no matter if you send it 5 characters or 50,000. The password that is stored is just a mathematical representation of the password.
As far as DDOS, It doesn’t matter what the limit is, you can send them millions of characters rven if they have a limit. If you’re going to DDOS you’re going to just use SYN flood, pings, for all of the matters you could send headers.
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.
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).
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.
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 headers (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 password.
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 crypted 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 a realistic risk.
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 block up front.
Why not client side hash? JS is more than capable.
Sure, you could do something like that to normalize all manner of passwords to a manageable string, but:
-
That hash becomes the password, and you have to treat it as such by hashing it again server side. There’s a high risk a developer that doesn’t understand skips hashing on the backend and ends up insecurely storing a valid password for the account “in the clear”
-
Your ability to audit the password for stupid crap in the way in is greatly reduced or at least more complicated. I suppose you can still cross reference the password against HIBP, since they use one way hash anyway as the data. In any event you move all this validation client side and that means an industrious user could disable them and use their bad idea password.
-
if you have any client contexts where JavaScript is forbidden, then this would not work. Admittedly, no script friendly web is all but extinct, but some niches still contend with that
-
Ultimately, it’s an overcomplication to cater to a user who is inflicting uselessly long passwords on themeselves. An audience that thinks they need such long passwords would also be pissed if the site used a truncated base64 of sha256 to get 24 ASCII characters as they would think it’s insecure. Note that I imply skipping rounds, which is fine in such a hypothetical and the real one way activity happens backend side.
-
You’ve got to stop all those who put: abcdefghijklmnopqrstuvwxyz
That’s my password for most things, any hackers die of RSI before they get in.
It’ll be caught by a dictionary attack. at least do something to break up their sequential order.
One of the accounts that I have to use at my job is like this but much much worse. It only accepts letters and numbers, no capitalization, no symbols and can only be 8 digits long maximum. It’s like they want to account to be easy to compromise.
That sounds like the limitations of an ancient mainframe system. If so, then someone trying to brute force their way in would be more likely to crash the system instead.
If I have to create a password Ill need to remember and don’t have access to my password manager for whatever reason I have a long phrase that’s my go to but I have a system about adding numbers and characters to it based on the context of the log in. Sites with character limits really fuck that up.
