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 had this problem with a fucking bank once. Even better are the sites that silently chop off characters after the internal limit, on the backend, but don’t tell you or limit the characters on the frontend. I had a really fun time with that last scenario once, resetting my password over and over and having it never work until I decided to just try a shorter password.
What’s more frustrating is when the password creation page is silently cutting off too long passwords and don’t inform you about it.
Back in the day, long time ago, Unix would do that, and limit user silently to 8 characters.
Which then wasn’t great, but a good password would be hard to break even at only 8 characters with equipment of the time.
We would do a cracking test against the user passwords periodically and ding users who got cracked. Well one user was shocked because they thought their 16 character password was super secure and there’s no way we would crack it. So we cited her password and she was shocked she went through so much trouble only for the computer to throw away half her awesome password.
Oh, I hate this one
There’s a site I use that does that on the password reset page, but not when logging in. So when using a long password it’s as if the reset never works. Took me ages to figure out what was going wrong.
I have a “cuts off special chars, wtf” somewhere in my password store.
My worst experience so far was a webpage that trimmed passwords to 20 characters in length without telling you. Good luck logging in afterwards…
As long as their login page also does that :p
I remember some office software that didn’t accept certain special characters but didn’t tell the user and just accepted the new password. I had to bother IT support many times to reset my password.
Common mistake for amateurs that found a password library and used it without reading the documentation. E. g. bcrypt will tell you to salt and hash the password before digesting it into constant length output for your database.
Salting before doing anything else is basic password security. I assume the webpage in question doesn’t do that, either.
One of my favorite memories of how much Something Awful’s sysadmins were absolutely amateur hour back in the early 2000s was the “lappy” to “laptop” debacle. Apparently Lowtax found the term “lappy” so annoying that he ordered his system administrator to do a find/replace for every instance of “lappy,” replacing them with “laptop.”
Unfortunately this included usernames and passwords, as well as anything that just managed to have the letters “lappy” in that order anywhere in the word. So, there was one user named ‘Clappy’ who woke up one day to find his name changed to ‘Claptop.’ Apparently this is also how people discovered that they were storing password unsalted in plain text in a fucking MySQL database, which if you’re old enough, you probably already remember that the combination of MySQL and PHPmyAdmin were like Swiss cheese when it comes to site defense. :p
Flaptop Bird
That must have done a lot of dawizard to their reputation.
oh. this has been a big pet peeve of mine for awhile. After starting to use password managers I figured I would standardize on the largest required characters only to find a source whos maximum characters were lower than anothers minimum characters.
How about creating a new account, letting bitwarden create a password, only for them to send me a clear text copy of that passwod in their confirmation email…
i thought that practice died like 20 years ago
Here’s your password, remember to write it down on your password post-it!
friendica does this.
…wut? Really?
That means the breach is imminent, but at least you won’t need to worry about other accounts when it happens. Just be sure you don’t give them any kind of PII or financial data to save. No, you can’t save my card data to make shopping easier, because you’re almost certainly going to have a data breach next month, and drag your heels about disclosing it, giving hackers plenty of time to commit a bunch of fraud using all of the cards on file.
Then again, there’s not much point to super long passwords. They’ll be turned into hashes, commonly of 128, 196, or 256 bits length. When brute forcing, by a certain length, it’s pretty much guaranteed there’s a shorter combination computing to the same hash. And an attacker doesn’t need your password, just some password that computes to the same hash. With 256 bit hashes a password with 1000 characters isn’t more secure than one with 15 in any meaningful way.
At one point years ago my work finally caught up with the 21st century and allowed creation of passwords longer than the fixed 8 characters it had always been. So I said great, made up something that was around 12 or so that I could remember. Until I logged into some terminal legacy programs we were still using and wouldn’t take that length. So yeah, I went back to 8 characters that wouldn’t break things. They eventually migrated away from such old programs and longer passwords became mandatory since they’d work everywhere, but I thought it was funny that briefly I tried to do the right thing but IT hadn’t thought out the whole picture yet.
My best experience… They allowed me to set a 100 characters password, but then changed the limits a year later, so that you couldn’t even login anymore.
And then they store it in plain text anyway…
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.
There’s a joke in there somewhere.
i once used 20 for a bank. the website havent told me it was too long just clipped off 2 and accepted the rest. not even the banking support was able to help me. took me a few days to solve this by accident.
That must have been frustrating. How many times did it lock you out from trying again?
This shit always pisses me off. I’ve encountered it in like 2-3 places over the years since I started using a password manager, and every time it’s so frustrating and hard to figure out.
Recently had a password that was acceptable for the account creation page on the website but too long for the login screen in the mobile app.
Took me a while to figure out that pasting into that field was just quietly dropping characters.
What is worse is when it does not quietly drop any characters and you have to keep resetting your password.
When both the account creation and the password reset fields accept more characters than the login this is an endless loop!
until
stackemail inbox overflow /s
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.
-
This shit pisses me off so bad. I had an identity theft a few years back, took ages to undo, and my credit score is still impacted by it. At the time I moved to a password manager and all my passwords are 31 characters of garbage. I’ve got several, highly sensitive accounts that my passwords don’t work for, in fact one a bank, until fairly recently, had repurposed a phone number field in the DB so passwords were limited to 10 characters numeric only (I managed to get one of their IT folks on the horn to explain why the password was so awful).
I cannot believe we live in 2025 and we still haven’t figured out passwords.
all our banks and government systems and may online services work on a governments own 2fa, and there are several variants. They are linked to phone and require inputting Pins. Very comfortable, very secure and very convenient. Also very fast.
Don’t get me wrong, there are systems that work. I built up a very successful smart card based system many years ago after a failed audit. I initially hated the idea but in the end we built a crazy secure environment that was very easy to use and maintain. That project is long since obsolete but after doing that one, over a decade ago, I figured things were headed in the right direction.
I think I’m extra sensitive right now because my aging mom has made the issue acute. She’s not the same as she was a few years ago and helping her with all her online accounts has become a nightmare. It’s just too complicated for many folks.
My bank forces a 6 digit PIN as a password.
Their 2fa is also email or text only.
At least we can set a unique username?
Yeah, I’m up to 40 hide my addresses for that same reason. Figure if the password sucks, at least the email can be unique and obscure.
168! Don’t hold back - everything gets a unique email address, a generated password, unique username and profile info.
It’s only the damn phone number that can be used to connect my data. Can’t do anything about that.
I have a google voice number for that. Most things no longer accept it though.
I just use a catch-all email domain. It’s functionally similar to a hide-my-email address, except the email addresses are much easier to read and remember.
Every single email that hits my domain goes to the same inbox. So Target@{my domain} and Walmart@{my domain} both hit the same inbox. And if I start seeing spam addressed to Target@{my domain} then I know Target sold my info. I can easily filter everything to that address straight to spam, with the exception of any senders ending in “@target.com”
It means my shit gets automatically sorted into neat little folders before it ever even hits my inbox. I can still get the birthday coupons, while all of the spam quietly vanishes into the spam inbox abyss.
I used to do this, but then why revealing even my domain. I have bitwarden integrated with simplelogin, and I get service_garbage@aliasdomain.tld
This way I can easily filter with prefix matching (if I want to), but don’t reveal anything at all about me. Also much easier to be consistent, block senders etc. Plus, I can send emails from all those addresses if I ever need (e.g., support).
I had delusions of trying to keep track of which address is sold by who which is why I did the hide my email addresses. But I’ve always kept separate personal and spam accounts. This was my attempt at combining to a single account.
deleted by creator
So long as attempts aren’t per IP and or ipv6 isn’t allowed
And as long as they don’t have an unknown database leak, negating the attempt limit.
We have figured out passwords. Management hasn’t figured out allocating resources to security, and governments haven’t figured out fining the crap out of such companies.
Is there any specific reason to using 31 random characters instead of 32?
Illogical meat brain that thinks odd numbers are more random that even I guess.
I’m not the one you’re asking, but I’ve had a case where using the maximum number lead to login issues. A character less did not have issues. Must have been an off-by-one implementation issue (maybe a text terminator character). 32 is a power of two number. Seems like a reasonable approach to evade such issues categorically - at the cost of a character by default of course.
Yes, haha, I saw your other comment about this off-by-one issue. Interesting that it happens at all.
