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.
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)
when you varchar(24) and forget about the hash
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?
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.
At least they tell you. I’ve had inputs take the full password and then truncate it silently, so you don’t actually know what they saved. Then, you try to login and they tell you wrong password.
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
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.
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.
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
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.
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
PayPal did the same. Registration took 40 characters, login only half of that. Editing the login form didn’t work unfortunately.
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.
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.
You never store passwords. They should be hashed and salted.
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
I don’t have it in me
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
We have a customer, a big international corporation, that has very specific rules for their intranet passwords:
- Must contain letters
- Must contain numbers
- Must contain special characters
- No repeats
- Passwords must be changed every two months
- Not the same password as any of the last seven
- PASSWORDS MUST BE EXACTLY EIGHT CHARACTERS LONG
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.
I can’t say who it is, but their name begins with ‘M’ and ends in ‘cAfee.’
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.
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.
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.
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).
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.
Meh, if they lock you out after X attempts, then 6 digits is fine. Hell, even 4 digits is fine if they have a lockout-policy.
Do they have a limit on attempts?
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.
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.
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?
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.
The claim was that a limit on passwords implies plaintext storage.
quoting the post:
Possibly indicating cleartext storage of a limited field (which is an absolute no-go), or
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.
but this in no way indicates clear text password storage.
It does.
No it doesn’t.
It does.
/80’s hacker turned Software Engineer turned Cybersecurity professional
deleted by creator
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.
The salt and the password (or its version after key stretching) are concatenated and fed to a cryptographic hash function, and the output hash value is then stored with the salt in a database. The salt does not need to be encrypted, because knowing the salt would not help the attacker.
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.
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.
Plaintext password (693 chars):
“hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2hunter2”Clientside SHA-512 hash (64 bytes):
7399ed78effda820b2187bc70f0549dd67f6846c595f944d198a1f1136cd0ab91119d6f208a34b4419e969b9ffb326d3786cecb90828f0ab36a5e3835558740c— Client sends 64 bytes to the server —
Serverside SHA-512 hash (64 bytes):
25293199e10af10e8a20f4ab38abccd2cdccd762d8cba2ed4871a2aea8fe6d9ffcc54cfe1c9cbd03245bfd2f0ee1039f06083b7bcbefd91b7fcbba182d588983At 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.
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 would be the other reason for a password length limit so low ? I could understand limiting to like 64 characters but 24 sounds low.
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.
Oh, I hate this one
I have a “cuts off special chars, wtf” somewhere in my password store.
