My password is not accepted because it is too long
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.
798
Comments275
I once registered an account with a random ~25 characters long password (Keepass PM) for buying tickets on https://uhuu.com.br/
The website allowed me to create the account just fine, but once I verified my e-mail, I couldn't log into it due to there being a character limit ONLY IN THE LOGIN PASSWORD FIELD. Atrocious.
EDIT: btw, the character limit was 12
It's pretty stupid because the longer the password the more secure it is.
I understand a cap of like 64 characters or something to keep storage space down for a company with millions of users. other than that it doesn't make a ton of sense.
That is a huge red flag if ever given as a reason, you never store the password.
You store a hash which is the same length regardless of the password.
Youre right lol. I forgot that hash lengths are different from the actually password length.
Although at some point you'll get collisions, but I don't think that's actually an issue. It still equally hard to guess a password from the hash, there will just be some solutions that are much longer than others.
You never store passwords. They should be hashed and salted.
The cap should actually be due to the hashing algorithm. Every password should be the exact same length once it is salted and hashed, so the actual length of the password doesn’t make a difference in regards to database size. The hash will be a set length, so the storage requirements will be the same regardless. Hashing algorithms have a maximum input length. IIRC the most popular ones return a result of 64-255 characters, and cap at 128 characters for input; Even an input of just “a” would return a 64 character hash. But the salt is also counted in that limit. So if they’re using a 32 character salt, then the functional cap would be 96 characters.
Low character caps are a huge red flag, because it means they’re likely not hashing your password at all. They’re just storing them in plaintext and capping the length to save storage space, which is the first mortal sin of password storage.
You can easily get the hash of whole files, there is no input size constraint with most hashing functions.
Special password hashing implementations do have a limit to guarantee constant runtime, as there the algorithm always takes as long as the worst-case longest input. The standard modern password hashing function (bcrypt) only considers the first 72 characters for that reason, though that cutoff is arbitrary and could easily be increased, and in some implementations is. Having differences past the 72nd character makes passwords receive the same hash there, so you could arbitrarily change the password on every login until the page updates their hashes to a longer password hashing function, at which point the password used at next login after the change will be locked in.
I’ve had this exact same thing happen.
I’ve also had it happen where you have the two fields to verify the password is the same. One had a maxlength set in it, and the other didn’t. I was for sure entering the same password and I was so confused until I opened up the dev tools and inspected the inputs.
I’ve seen this behavior too, I forget where. For me it was a bit easier since the fields displayed a different number of stars. I did spend too long trying to figure out how my password manager could be failing that way
Okay so I agree with you that a longer password is better but this in no way indicates clear text password storage.
Is the maximum 24 characters because their database column is a VARCHAR(24)? That's one of the first questions that I thought of. Sure, it doesn't guarantee plaintext, but it's a indicator that it may be stored plaintext, considering hashing doesn't care about length. Or at the very least whoever has had eyes on this code doesn't know shit about security, which makes me less confident in the product as a whole.
The only reason I can think of to have a maximum would be to save on bandwidth and CPU cycles, and even then 24 characters is ridiculously stingy when the difference would be negligible.
Oh look, a free account!
bcrypt hashes only the first 72 bytes. 24 characters is the max amount of 4 byte UTF8 characters when using bcrypt. Which is stupid because UTF8 is variable, but still, it's a possible explanation.
A good reason to switch to argon :)
To be fair, 24 is still a secure length for a password, and will probably be for another 5-10+ years.
Cryptographic hash functions actually have fixed runtime too, to avoid timing-based attacks.
So correct password implementations use the same storage and cpu-time regardless of the password.
I figured it was about the time spent transmitting. But the password should probably be hashed before sending as well as upon arrival at the server, correct?
It isn't usually. If it was, the server-side function wouldn't need a constant runtime at different-length inputs since the inputs would not have differing lengths.
The problem with client-side hashing is that it is very slow (client-side code is javascript (for the forseeable future unless compatibility is sacrificed)), unpredictable (many different browsers with differing feature-sets and bugs), and timing-based attacks could also be performed in the client by say a compromised browser-addon.
For transit a lot of packaging steps will round off transfer-sizes anyhow, you typically generate constant physical activity up to around 1kB. Ethernet MTU sits at ~1500 bytes for example, so a packet of 200 bytes with a 64 char password or a packet of 1400 bytes with a 1024 char password containing some emoji will time exactly identically in your local network.
I would have thought the opposite. I remember having a familiar conversation: “we need a sanity check in the password: what would no sane person do?” I believe we cut it off at 64 characters, but I can see someone thinking 24 is kore than enough, if they’ve never used a password generator.
It does. If you hash the user passwords, which you should, the hash is always the same length and it's thus irrelevant how many characters the user's password consists of.
Now, it's not certain though, which wasn't claimed either, because the front end developer might have other reasons for setting limits. The backend shouldn't care though.
The backend should care though. Even if strings can have an unlimited amount of characters, you don't want to go and hash a gigabyte of data. In lower level languages you don't have magic strings either so you might do something like
char password[64].There's many reasons to limit raw password length. Not many good ones to have it as small as 24 (or even 64) though.
There should be a limit. It should be so high that we never hear about it. 1MB for example.
Exactly. The tax on hashing the password can't be ignored and if you're doing this enough times it can kill a system. 24 characters is too low. I'd say 100 characters is enough for most use cases. 1024 if you're feeling 1337.
Sure, but when we talk about the computation then the number of rounds is by far the more important factor compared to password length.
The discussion is about whether 24 characters indicate cleartext though - not whether password lengths should be in the gigabytes.
Seems reasonable.
I agree you might have threat actors looking to DoS your system if there's a publicly exposed REST endpoint accepting gigabytes of data. That has nothing to do with the discussion on password hashing though.
The claim was that a limit on passwords implies plaintext storage. It doesn't. There is no such thing as unlimited on computers.
quoting the post:
It was not a claim that it certainly is plaintext storage. It was claimed to be a possibility. AND provided an alternative explanation.
Maybe you're more confident than me in good practices and implementations across all services. But I've seen enough to know that's not always the case. It's good to be skeptical on anything related to security.
No it doesn't.
It does.
/80's hacker turned Software Engineer turned Cybersecurity professional
Don't worry, I'm autistic myself and understand how difficult it can be to parse "it's thus irrelevant how many characters the user's password consists of" to mean something besides "all implementations must accept an unlimited amount of characters".
I do believe the point was understood by the general reader however.
What an awful thing to say. Go question your motives.
Curiousity: Could you please explain what was awful about the comment you responded to?
For context, I'm also autistic.
There is no good reason so send the passwors itself to the server. Send the hash and you will have a fixes length of data to send anyway.
And even if insist in sending the password over the wire, there is no problem on the backend to handle longer passwords than that, so that no one will run into a limit in practice. We're talking about bytes here, not even a kb.
Proper hashing of a password includes a salt that should be kept private. This means the password should definitely be passed to the server in plaintext. The server adds the salt to the password, then hashes it.
This adds more protection should an attacker somehow manage to get access to your hashed passwords. Even if they identify the type of hashing mechanism used it will prevent the use of rainbow tables, dictionary attacks, etc. against the hashes.
While I'm not arguing for doing the crypto client side, the salt isn't needed to be private - only unique.
It definitely needs to be private. If an attacker can obtain both the password hashes and the salt(s) (via the same database vulnerability for example) then they have everything they need to run offline attacks against the passwords.
No, it most definitely does not need to be private. The idea with salt is to invalidate rainbow tables. If you're "keeping it private" it's just another password.
https://en.wikipedia.org/wiki/Salt_(cryptography)
The salt is specifically to invalidate pre-generated rainbow tables, and doesn’t need to be kept private. It only needs to be unique.
The attacker generates rainbow tables by running common passwords through known hashing algorithms. So I run “password1” through a bunch of different algorithms, and save the results of each. Notably, generating decently large rainbow tables takes a lot of time, processing power, and storage space. Because you don’t just use common passwords; You’re basically running a brute force/dictionary attack on your own computer’s hashing algorithm.
Now if a database is unsalted, I can search for matching results against my rainbow table. When I see a match, it tells me both which users had that password and which hashing algorithm they were using. So now I can narrow down my focus to only using that algorithm.
But if a database is salted, all of my pre-generated tables are useless. Even if someone used “password”, it won’t match my rainbow tables because the hash was actually fed “password{hash}” instead. And even if multiple users used “password”, each salt is unique, so I don’t see a bunch of repeated hashes (which would point to those accounts using the same password). I would now need to generate all new tables with the salts I stole in order for my rainbow tables to be usable again. And even then, I’d need to repeat that table generation for every user.
If that were the case you could still hash it on the client side, forcing it to be a certain size and then hash it again on the server with the right salt. I don't think there's a real disadvantage to hashing a hash.
you absolutely should not be hashing client side. You need to securely transmit the password to the server where it is hashed. You do not want clients knowing /how/ the password is salted/hashed. this lowers your security overall.
If you're doing hashing and salting on the client then yep it's useless, no difference to just using a hash output as a password.
If on the other hand you're doing a zero-knowledge password proof method then it's quite secure. As the password is never transmitted over the network, not even the server knows what it is, but can still verify the user has the correct one.
There's some software that hashes the password clientside before sending it, sure. But it still should be hashed serverside too.
If the server hashes a hash, the plaintext password's length is still irrelevant
That's not true. There's limits everywhere.
At no point the server has to deal with the length of the plaintext
It could be an older codebase that’s using an inline encryption algorithm as opposed to a hash. Using an encryption algorithm with a private key would result in varying length outputs.
That's the same as "cleartext" for someone who works in security though, since that means anyone with the private key can decrypt the password.
Password hashes always have the same length.
Why is there a limit at 24? It may be an arbitrary limit set, or it may be because they don't store more.
What would be the other reason for a password length limit so low ? I could understand limiting to like 64 characters but 24 sounds low.
I heard some banks encrypt single characters of the password separately (no idea how that would be safe) they often ask to provide random characters from the password instead of the entire password.
My bank only accepts up to 20 characters. It doesn't validate it... The login page simply ignores all characters beyond 20th. So I didn't even know that it cut my password until I tried to log into the mobile app, which replaces the last character when you type more than 20... that was confusing 20 minutes when I didn't know why I can't log into my mobile app.
What’s more frustrating is when the password creation page is silently cutting off too long passwords and don’t inform you about it.
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.
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.
I have a "cuts off special chars, wtf" somewhere in my password store.
Oh, I hate this one
I once encountered a system that truncated your submitted password if you logged in through their app, but not through their website. So you would set your password through the website, verify that the login was working (through the website) and then have that same login fail through the app.
Yes I've had issues with this as well, since I'm a child I've set my password generator length at 69 characters... A small trick I've found is to delete and rewrite the last character of one of the two repeated passwords since often the validity check gets triggered on write but not on paste
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.
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 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.
https://xkcd.com/927/
I used to do this, but then why revealing even my domain. I have bitwarden integrated with simplelogin, and I get [email protected]
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).
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?
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.
Illogical meat brain that thinks odd numbers are more random that even I guess.
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 worst experience so far was a webpage that trimmed passwords to 20 characters in length without telling you. Good luck logging in afterwards...
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.
As long as their login page also does that :p
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.
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.
We have a customer, a big international corporation, that has very specific rules for their intranet passwords:
I can only assume that whoever came up with these rules is either an especially demented BofH, or they have some really really weird legacy infrastructure to deal with.
I am a designer, but I once did a project with a very very major and recognizable tech corporation that, no joke, implemented an 8 character limit on passwords for storage reasons.
This company made in the tune of tens of billions of dollars per year, and they were penny-pinching on literal bytes of data.
I can't say who it is, but their name begins with 'M' and ends in 'cAfee.'
If password length affects storage size then something has gone very wrong. They should be hashed, not encrypted or in plaintext.
Whoever the company is, we have to assume it's not a security-related company. Because, surely, none of those would do that ever.
No repeats??? Like, you cant have 'aaaa123@' as a password?
You're just making it easier to brute force...
Since the password has to be changed every two months, I would assume that it means no repeating previously used passwords.
It also says "must not be the same as any of the last seven passwords used" so I can only take "no repeats" to mean no repeated characters.
Requiring passwords to be exactly 8 characters is especially ridiculous because even if they're cheaping out on bytes of storage, that's completely cancelled out by the fact that they're storing the last seven passwords used.
You’re right, I didn’t noticed the 7 passwords line.
I worked in IT for a big national company for a short time. Passwords rules were : at least 8 characters, at least one uppercase letter, at least one number, change password every 2/3 months and different than the 3 previous ones. Several workers had a post-it on the screen with the 4 passwords they use. One of them had name of child and year of birth, I don't know if it was his children or his relatives' children too.
Your password MUST contain big and small letters, and contain at least 1 number character and 1 spacial character, it MUST be 8 characters long, and it MUST be typed on a German Cherry keyboard between 8-9 PM, using ONLY 1 finger while blindfolded and listening to ABBA music. BUT NO SPACES ALLOWED!!!
This is because of something called entropy we never even read about so we have zero understanding of it. Of course combined with lousy programming, so safety is all on you.
Making all these possibilities OPTIONAL would actually make for safer passwords (higher entropy), as would using multiple words separated by spaces. The only meaningful way to accept a password would be to test it against common bad passwords, and test the entropy to determine acceptable levels. There is no good reason a password couldn't be 10 words and at least 127 characters. There is no way that should stress a properly designed modern system.
You have described all of the guidelines that NIST, Microsoft, GCHQ and a few other institutions now recommend for password security.
And yet I still have to have this argument with so-called security engineers and my favourite, compliance officers.
Because they are morons that don't understand entropy.
Requiring at least 1 number increases entropy less than simply allowing the use of numbers, and then recommending it.
But most password queries are lousy at describing what's allowed when creating it, and they generally don't describe it at all when you enter it for access.
The second part can be crucial for remembering exactly how the password was created, because what is now required, used to often not even be possible to use!
you forgot that you can only use a selection of special characters from a pre approved list of 10.
Had that yesterday.
"Must use special characters!"
"Okay, no problem. Here you go."
"Not that one! It's too special!"
"Dude, I haven't even touched extended ASCII yet."
A pre-approved list of 10 which THEY DON'T EVEN TELL YOU WHAT THEY ARE
I love when there are so many rules that my first few randomly-generated passwords are rejected.
Even worse, when you can’t figure out why, or how to configure the generator, then end up having to type your own anyway
genuinely, whats up with not being able to use spaces?
I think it's originally because of bad programming. It's so incredibly stupid I don't have words.
I like the ones that just tell you your password strength.
Subtle shaming of bad passwords without giving bad actors hints as to what the minimum (and thus most likely) password is.
My mum told be the other day she logged onto a new bank, gave it a 12 character password then couldn't get back in after. When she got through to their customer services they said that it was an 8 character password limit (!), but it just never said on the register screen.
Yeah, I'd be doing that bank if there's any choice.
Edit: Leaving (my attention got taken away as I posted)
Either this is some new slang I'm not rizz enough to understand or one of us had a stroke.
He just wants to have sex with the bank.
No cap
Tain planet, he's our hero.
Microsoft does this to our users at my job. They go to charge their password and it won’t accept it but won’t tell them what the requirements are. “Your password doesn’t meet our criteria.” Okay, so what are you looking for???
Worst is that there seems to be a soft block at some point and instead of telling them that, it shows this dumb error instead over and over again no matter what password they choose.
Maybe that's security by obscurity. Or security by confusion. /s
so secure, no one can get in, even her!
Ah must be my bank. Same.
I've had a case in the past where I reduced my password to the limit, but after account creation, I was not able to log in.
Turns out they had an off-by-one issue, and a password with a length slightly below the limit worked fine.
I once got locked out of an HP printer because it chopped off the last few characters of a password. Only figured it out because somebody had made a comment online about password length
Experienced a site some years ago that let me I put however long password I wanted (my default is 52 in my password manager), but turns out it only used the first 20 or so.
Here's your password, remember to write it down on your password post-it!
i thought that practice died like 20 years ago
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.
friendica does this.
…wut? Really?
My favorite is when they don't have this check, but silently slice the string to meet the requirement, so that you can't login with the original password the next time.
Wells Fargo used to do this. They cut my 16 character password to 8 and negated capitalization. Which is why I don't use them anymore
amazon also had it a couple years ago
My bank used to do that back in the early 2000's, I moved banks.
Metro Bank did something like this to me.
Don’t worry, pretty soon they will just block password managers from autofilling fields on their login page so that you HAVE to remember your password! Then you’ll be happy it can’t be that long, you can only fit so much on a post-it note on the side of your monitor
/s
EDIT: I think there should be a law against blocking password managers for filling in fields. Any brute force bots are going to submit HTTP requests directly anyway; no one is hitting the DOM to do that
I’ve never heard of anyone trying to do that. I couldn’t even imagine how a website could detect a password manager.
I've seen a couple of times. It's the same ones that block copy/paste on password fields. The workaround is to write a short python script using pyautogui or similar to "type" out the clipboard content.
I've had banks do it in the past. It's not that they can "detect" the password manager, they just use a method that's incompatible with them.
They have a fake input field and capture keypress events via JavaScript directly from the dom, then just make it look like you typed in to the input field. They don't read the password from the input field, they build it up in memory from those key press events.
It also completely breaks accessibility software, which is the main reason I think the industry moved away from doing it for the most part.
For a system I worked on a few years ago I got the password requirement:
Only upper case letters A-Z, no letter or symbols.
Exactly 7 characters.
I was also recommended to make it a single word to make it memorable.
PASSWOR
'Sorry but this password is already taken'
By user [email protected]
That sounds like a game. Guess the word[s].
funniest experience that ive had is that i made a psn (playstation network) account with a 64 (iirc, might have been 32, dont remember) character password. That worked making the account on my PC on their website. Never was able to log into that account on my playstation tho and the error message was just some generic error. Support didnt know what was going on and i didnt either until it dawned on me. The password was too long for the console. Changed the whole thing to a shorter one and now it works everywhere. Used to work on their website, not in the app, not on console. Fun.
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.
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.
That must have been frustrating. How many times did it lock you out from trying again?
The password should be hashed anyway, which has a fixed output
But there must be a (long) max length anyway, to prevent some kinds of attacks.
Long here means a 400 page book as a password.
One of the older, but still usable password hash uses only 72 characters iirc.
I think if people have 400 page book long passwords it doesn't really need a unique hash
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 /sI don't have it in me
https://neal.fun/password-game/
I spent way too much time on this the first time I came across it
Joyously frustrating game
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.
c/passwordtoostrong
One time I worked a job where you had to make EXACTLY a 12 character password using only ten letters and two numbers.
That's insane.
But you could decide on the positions of letters and numbers? While it had to be exactly 10 and two?
I think so yeah. It's been about ten years since then though. I remember it being wildly short, and a set length with all letters and two numbers with no symbols. I also remember having to change it every quarter or something, so I just started at a number and every four months just upping it by 1. I was only there for about two years though and that job was crap, so it didn't matter very much.
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.
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.
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).
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.
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.
The password on my PC is something like 30 characters long. Back when win10 was first coming out, they were pushing getting an actual outlook account and tying that to your login. I was hesitant at first, but figured I'd try it out and see how that worked for me.
Turns out outlook accounts (at the time) had something like a 16 character limit on passwords. Bruh.
When I banked with wells fucking fargo they had issues similar to this. I had something like a 16 character password and I once forgot the last character and it accepted it anyway, so there was some kind of character limit that they didn't make obvious.
I also had a time I accidentally had caps lock on, and my password still was accepted. Their passwords were not case sensitive even though their password screen says they were.
That's insane
Obligatory https://neal.fun/password-game/
I don't understand rule 5. "Digits shall add up to 25" I have a 1 and a 24, and it doesn't accept it :(figured it out, it adds digits, not numbers
When that was first making the rounds I shared it with my coworkers. Most of my coworkers enjoyed it for a few minutes then moved on. One of my coworkers sent me a teams message 3 days later of the win message
Kudos for the dedication, I gave up at the fire thing
Yeah I never got passed the fire thing, or the egg hatching, whichever comes second
Happens more and more often
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.
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.
This seems to be very common still
Banks are the fucking worst for this. I assume it's because they're built on some 500 year old CICS mainframe.
And then they store it in plain text anyway...
24 is fine, not as bad as 12 and no special character. That's honestly the worst one i've encounter.
my bank app doesn't allow copy paste so i can't have anything that long and hard to type, and they tend to request password login when transferring money.
24 is not fine if you're like me and use passphrases sometimes
A 24 char passphrase while not as bulletproof as a machine generated string is still credibly strong even to offline cracking attacks when possible. In all the datasets of passwords acquired through that sort of cracking I don't think I've ever seen it catch even a 4 word passphrase.
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.
Some people even suggest typing a longer password over a simpler one with more special characters. It's harder to brute force.
I thought the use vocabulary lookup tables effectively nullifies the entropy benefits, if everyone started using phrases as password
Obligatory xkcd.
I don't know enough to say how accurate the numbers are, but the sentiment stands - if it's a password you're memorizing, longer password will probably be better.
That's not even the case though. Using a memorized passphrase that can be broken down into individual words is susceptible to dictionary attacks provided you know what the length of the password is. You can algorithmically sort away swathes of the dictionary based on how many likely word combinations exist before searching unusual word combinations. The thing is, passwords suck. It doesn't matter how long the password is, if someone wants in, they'll crack the password or steal it via some other means. Instead of relying on a strong password, you need to be relying on additional proof factors for sign in. Proper MFA with actual secure implementation is far more secure than any password scheme. And additionally, hardware key authentication is even more secure. If you are signing into an account and storing important data there, you do not want to rely on passwords to keep that data secure.
The reason for the character limit on passwords is often to prevent malicious attacks via data dumping in the password dialogue box. Longer numbers take more CPU cycles to properly salt and encrypt. Malicious actors may dump as many characters in a password system as they wish if they wanted to take down a service or at least hurt performance.
Additionally, even if you just used lowercase letters, an 18 character password would take 12 RTX 5090s approximately 284 thousand years to crack according to the recent Hive Systems report.
24 characters is more than enough to be secure as far as passwords alone go. Just know that, nobody is out here brute forcing passwords at any length these days, there are infinite more clever ways of hacking accounts than that.
Assuming the attacker knows it's a phrase: The english language alone apparently has some 800.000 words. 800.000^6 = 2*10^35 combinations in a dictionary attack. That's comparable to 18 random ASCII characters. We might also be using a different language, or a combination of languages, or we might deliberately misspell words.
A long string of random characters will give you more combinations per password length, but there are some passwords you just need to be able to memorize, and I'd say that's more likely with the 6 words.
At least they tell you. I signed up with websites that just cut the password after the 12th character. No way of signing in with the password again (not without trying a couple of times, at least)
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's the combination to my luggage!
That would suck to enter. Much better to do qwertyuiopasdfhhjklzxcvbnm
Or if you are cool: pyfgcrlaoeuidhnnsjkxbmwvq
is that Dvorak I spy?
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.
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.
YES, it pisses me off so much. Though I do kind see for some things having some upper limit of 256 for certain services. But I may be wrong in thinking that.
For example I want a secure bank password but I only need it so long. Mainly because unlike my E2EE service if they are servered a warrant or hacked through another service all my data is there. Basically I can only do so much.
when you varchar(24) and forget about the hash
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.
I like it that the site says the max length....this is not common. I wish it was.
The problem is a password hash is a fixed length regardless of the password, so if this is implemented correctly there is no need for a maximum password length. These things raise my security flag because it makes me think they are storing the password in plain text instead of doing proper practice and storing the hash only.
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.
Being regected for being too long. What a conundrum.
Do you have a source for the 24?
I can find a 72 byte limit. (Wikipedia, article) That's three times as many [ascii] utf8 characters I could use.
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
Good to know
I was just speculating
Most likely it's just a validation not related to actual storage of the information.
It's something that can happen automagically when using a library. I wouldn't be too surprised if this length limitation is just a default of whatever registration solution they are using.
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.
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
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.
It can also be just a randomly chosen limit. I work as a software engineer on a custom management software for a big client. For whatever reason until recently, the limit for email addresses in the master data was 50 character. Why? No clue but someone had decided that randomly in the past. Now it was increased to 100. Why again? According to RFC 5321 a limit of 254 would be the most sensible one. But the people who come up with those requirements just don't care. They decided it to be 100 from now on for no apparent reason.
Then we have many input fields, that have a limit of 255 character. Why not 256? Why such a weird number in general? The people who use this software in production are most likely not the ones who usually think in powers of two. So why not make it 250 or 300 oder whatever?
Sometimes those limits are just arbitrary with no technical or logical reason to back them up. Which doesn't make it less stupid mind you.
255 chars + '\0' = 256
Not weird at all.
I see your point, but we have Java backends and strings there are not null terminated. Also I'm very sure that those would never be the reason for our Postgres server to run out of storage so I don't get it why not make it more user friendly. We're not implenting an embedded system where every byte of storage counts.
Agree, I was just commenting on why 255 in itself isn't "weird". I find myself doing comparisons of the "value == variable" type even in languages where you cannot assign by mistake. Some of us old farts code from muscle memory ... :)
There's a joke in there somewhere.
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:
I haven't logged in for years so I'm not sure if it is still working that way.
a game i played doesnt allow special characthers or its too long.
A game I play used to not care about it being a capital letter or not. Hunter2 and HuNTeR2 would both work perfectly fine.
I decided to be a smartass once and made a 63 character long password.
It wasn't too bad at a keyboard, though if you make a type you're screwed.
Trying to use my AD account to access admin tools on printer? I got it fixed, and immediately changed my password, lol.
This is only true up to a certain point
Explain please, I'm curious
Oh wow! Didn't expect a detailed explanation of this. Thank you kind Lemmy user!
All passwords longer than eight characters are silently truncated anyway.
Only by very badly designed systems. Most are not truncated but hashed. Those hashes are much longer than 8 characters.
Looks like somebody made a generality out of the Shamir Secret Sharing PayPal implem (read it thought)
good read. TLDR is that Sun Microsystems database software truncated passwords to 8 characters and the OP assumed that others must do that too. I surely hope not, TBH. I thought truncating to 8 characters had to do with computational or storage efficiency back when that mattered. I'm pretty sure most database fields if they're modern use like a 256 character limit for passwords right?
..
Wasn’t it one of the first us govt encryption algorithms, operated on 8 byte blocks?
Uh? Why?
Only by batshit insane system wreckers. Normal systems don't do this at all.
Is that point 24 - the limit they set?
Passphrases are much stronger than any 10 character password you can conjure up
How does that contradict my statement? 10 chars is pretty weak.
What's the point? no one is brute forcing a 12-15 password if the login system has ANY login attempt protection anyway.
This seems like one of the extreme overkill things...
Do you check on login attempt protection behavior before creating accounts, and then choose your password length accordingly - longer or shorter?
That doesn't help if someone got a list of their hashes somehow. Then an attacker can use their own system to crack them.
And that's if they aren't just storing the passwords as clear text to begin with, which length limitations are often a sign of.
Such a small max length is a good indicator they aren't handling passwords correctly. A modern website should be able to send and hash kilobytes of text without the user seeing a significant delay. Having a max size like this sounds like they are storing the password as text instead of a hash.
Or some dumb project manager said passwords longer than 24 characters look bad in the UI and wanted the limit.
too many people ITT not decrying passwords for certified session security keys on the 21st post quantum era. smh.
There is little point of having a long password. Online accounts don't have the same issues as encryption
Edit: for those curious, here is my source https://cybersecuritynews.com/nist-rules-password-security/
My rationale is that online accounts typically don't get brute forced due to rate limiting and not protection. The NIST guidelines don't specify requirements for online accounts specifically but it does recommend a password of 16 characters in general. I don't really see any need to go above that as you are just making it harder on yourself.
I really hope you don't work in the tech industry.
I've yet to see anyone link to a source
Here is where I'm getting my info
https://cybersecuritynews.com/nist-rules-password-security/
you realize that they say the exact opposite of what you are saying, right?
You haven't provided any evidence to support your claim. Online accounts can't easily be brute forced.
If a hash is leaked you just change the password. As long as you aren't reusing the same password everywhere you are fine.
If the hashes are leaked and that’s immediately caught and customers are immediately informed, just change your password.
How do you know when a password is leaked?
What's the distribution of variance in brute force protections on online services?
Why would it matter? If they can access the password they probably can access everything else on that service. Just don't reuse passwords.
That's simply false. Increased length increases the entropy of a password, making it harder to brute force to gain access.
You have to go out of your way to restrict the length of passwords. There's absolutely no reason to do it, and it is contrary to all good security practices.
I'm not sure how you expect someone to brute force a web service. It is possible but it would be equivalent to a denial of service. Having long passwords for a online login makes no sense. A randomly generated 12 character password isn't any more or less secure than a 40 character password since they both take a unrealistic amount of time to brute force.
A 12 character password made up of standard characters would take 475,920,314,814,253,376,475,136 tries assuming you know the length. I don't see how someone could brute force a web service.
I will say I get annoyed at web services that require special characters since I like to use 3 words from the EFF extended word list.
how braindead are you?
How old are you?
The old security wisdom has been thrown out in favor of better practices. If you spend to much time focusing on one spot you will make everyone hate you while leaving gapping holes in your security.
your comments just make me hope that you never touch an IT system as a developer
https://xkcd.com/936/
Also https://xkcd.com/538/
I love wordlists
Think of it from a random guess perspective. Guessing a number randomly generated between 0-16 is easier than guessing one between 0-8.
Now think that all passwords are stored in certain amount of bits, so let's compare 4 and 8 bits.
Each bit has a chance to be either 0 or 1, so guessing a single bit's possibility is 1/2.
Guessing the correct orientation of 4 different bits takes 1/2^4^ = 1/16
Guessing the correct orientation of 8 different bits takes 1/2^8^ = 1/256
Now think passwords being stored in more bits(=longer password)
At a certain point it doesn't matter as the password is effectively unguessable.
One weakness with longer passwords is that if they are created by humans chances are it will be easier to guess the pattern. This is true for all human created passwords but I think the longer ones are worse since there is more space to create a easily guessable pattern.
Assuming a breach, and hashes are released, its significantly harder to bruteforce a long password.
Some (a lot) poorly set up websites may not even have a limit on password attempts, or cooldowns.
It won't matter if you use a password manager. You shouldn't rely on the website to keep your password safe. They could be storing it in plain text for all you know. (It has happened before)
pls elaborate
As long as the adversary doesn't have the ability to brute force the password locally, you have the ability to reset in the event of a leaked hash and you aren't reusing passwords you are fine with a shorter password. Obviously be mindful of easily guessable passwords or ones that are very short. However, a 12 digit sufficiently random password is fine. Don't fall into the trap of longer but easier to guess.
Don't do things like impossiblebatman1. Something like SalariedOverhand22 or imposiba1ttman
The first secure one I used diceware to generate two random words and then a random number generator to add a number. The second one I randomly changed spelling and the pattern to increase entropy.