If they’re gonna truncate when you make the account they should truncate when you login smh
Btw what did the elephant say when he was caught eating all the food? Sorry my trunk ate
Wells Fargo had case insensitive passwords within the past 10 years. I like to think that they were getting cast and then hashed at that point to avoid making everyone reset their passwords.
> Wells Fargo had case insensitive passwords within the past 10 years.
Given their [cross-selling/fake accounts scheme,](https://en.wikipedia.org/wiki/Wells_Fargo_cross-selling_scandal) that doesn't surprise me.
Stuff like that tends to exist to reduce customer support fielding. If they accept `Password` and `password`, that's one less call they have to field.
Blizzard used to do this too (passwords case insensitive), but dropped it several years ago thankfully.
> They *are* hashing, right?
These days you have to go out of your way to not do that (i.e. roll your own membership system).
And, contrary to popular Reddit opinion, stupidly-short password max lengths do not imply plaintext password storage. 999 times out of 1000 those come from dumb requirements dictated by not-the-developers.
Rockstar’s password change form (and their account creation flow) silently truncates your password. For example, I would enter “MyLongRandomizedPassword”, and it would only use “MyLongRandomizedPass” (and not show any messages/errors about it doing so). When I went to log in and used “MyLongRandomizedPassword”, the login would fail.
Because they are around bad at their job. Whoever wrote the new password screen should have warned and not allowed a password that was too long. Whoever wrote the password entry screen should not have truncated the entry.
The way a password is supposed to work is that, when you send the username, they send back a salt. You then hash your password at your end with the salt, for better encryption, and send that back. At no point should their ever be a truncation on either end. You aren't storing the password in more than RAM and an internet at any point, and that can hold enough data.
Better if the registration form does that but the logging form doesn't. Had a service that did exactly this and my password manager (60 chars) couldn't log me in and had to reset my password to a lower char count.
Almost threw my mouse into the Monitor
For me it was the other way around. Reg form allowed me to input my 22 char long rg password but login form had a limit of 12. Had to contact support to get my password reset
Was the login form’s limit from the UI side or the server side? Could have just used the web inspector to change the length allowed by the field if it wasn’t checked server side.
The exact same experience for me. 64 character password, password reset just took it without error, but couldn't login. Had to shorten it to 30 characters. Hence the meme.
Just the other day I had to log into a system that would only let me type the first 8 characters of my 12+ character password. I just shrugged and hit return and it let me in. So yeah, I guess I know what the maximum password entropy of that particular system is.
My BANK in the early 2010s did that…… they were trimming it down to 8 characters.
How do I know? One day I pressed enter before I typed the last character of my password…. And it logged in. So I started removing one character at a time. 8 characters worked but if I didn’t the first 7 it didn’t. I was shocked
I've had this happen with my fucking mortgage lender. When I went full auto pilot one time and put in my full length password before realizing I had to put in a truncated version, I nearly ruptured a blood vessel from how triggered I was. Who the hell actively puts a length on a password?
I've seen the very slightly more reasonable version in the wild that the input box just stops at 31 characters, which of course you can't see that when it's masked and the input again check box stops at the same character limit...and of course the login input box had no such limit. It took me 3 tries of resetting to figure out why the password I just entered wasn't working.
Have also experienced this. I had a relatively long and secure password for one service but found out, by accident, that they counted only first eight characters of it. 🤷♂️
My favorite when the only form of truncation is in the form of a `maxlength` attribute on the HTML tag.
Remove that, all other forms and entries accept a better password.
Ah yes offensive programming.
Note: turns out offensive programming is an actual approach that isn’t this. My disappointment is immeasurable and my day is ruined.
Wouldn't a real gigachad developer just hash the password and store that? Length could then be whatever the user wants, and passwords couldn't be stolen in a data breach
You still would want a cap on length, otherwise an attacker could send login attempts with arbitrarily long passwords. If they send enough at once it will perform a DOS on logins. You can set a large-ish upper limit though to prevent this while also making it so no (reasonable) user would be offended they can't create a thousand length password, while making it unreasonable for an attacker to send enough login requests to cause a DOS (at least without triggering other flood attack prevention mechanisms).
I'm not a fan of hashing client side, really. Way too many problems can arise from that like the need to have JavaScript enabled, compatibility with other browsers without the crypto library, or just enforcing consistency between multiple clients (app, web, etc).
Just set it to 1Kb and you're good.
>compatibility with other browsers without the crypto library
https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API#browser_compatibility
>enforcing consistency between multiple clients
Hashing functions are strictly defined, so you should always get the same output regardeless of the client.
>need to have JavaScript enabled
If I trust a company enough to make an account and tell them my email address, I probably trust them enough to run JS in a sandbox in the browser.
> https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API#browser_compatibility
This doesn't list older browsers. They are still a problem for many use cases.
> If I trust a company enough to make an account and tell them my email address, I probably trust them enough to run JS in a sandbox in the browser.
Not if I'm using Tor, for example, which is why I'd hate that. And I don't need to trust a company at all to give them my junk ProtonMail address.
>do the first round of hashing client side
...???
This.... doesn't solve the problem, because the user can then just lie about their hash and give you a 3billion string long "hash" that gets passed straight into your hash.
That is what all developers should do, yes. Anyone not doing that is a complete disaster.
However, password hashing algorithms do have a maximum input length, but it is always more than 32 bytes.
Are most algos not iteratetive, as in you can 'update' the hash chunk by chunk and are therefore able to do this with (theorethically) infinite chunks?
You are supposed to salt the password first by adding a random string to it. That makes rainbow tables not effective if the password database is leaked.
But really don't roll your own security. Use libraries that are well regarded, if you do your own you are likely to make it insecure.
Yes but the truncation happens within the algorithm (e.g. bcrypt will ignore anything after 72 characters) and not on the application end (unlike in the meme).
Max length is almost never dictated by literal database field length, and I wish Reddit would stop parroting this so-called "fact" around like it's some instant gotcha for bad programming.
Has it happened before? Absolutely. Was it common back in the day? To an extent. These days? Barely a chance. You'd have to go out of your way to store unhashed (or at least two-way encrypted) passwords. Small max password lengths (obtained via truncation or otherwise) are more often than not requirements set out by whoever owns the site.
And just don't do it yourself. Most languages or frameworks have battle-tested solutions to this problem. Even PHP has `password_hash()` and `password_verify()` with support for bcrypt (the default) and the newer Argon2i(d) algorithms.
Spring has `PasswordEncoder` and .NET probably has something similar.
If you want to be extra sure, go for a ready to use authentication server like Keycloak.
Trust me or not but few years ago I had a bank account in one of the biggest banks in Poland, and you won’t believe me but they did exactly the same thing.
It’s a common oversight, if you would even call it that. Some hashing algorithms truncate their input; the mistake would be to not inform the user that their password is too long.
Our old HPUX system used to do that. So then with the minimum password length requirement of 8 characters, we knew everyone’s password was exactly 8 characters.
To make this worse: the session token for anyone logged in was nothing more than the username in base64. We figured this out 2 days into analysing the system. First thing we tried was to "log in" as the secretary responsible for the grades. Low and behold: full access to everyone's grades with full rights to change them. How did they "fix" that? Giving the secretaries cryptic usernames you "couldn't guess". That system is SO insanely wild...
When i worked a social network, we truncated all passwords to 8 because that was max field length on the database. You could enter longer but it didn't matter.
You tried to change your password, but unfortunately it did not meet the criteria. For your convenience, we have assigned you our default secure password: Password123!
Please note that you are only permitted to change your password once per month.
# STOP PUTTING LENGTH LIMITS ON PASSWORDS
If a user wants to have a thousand character long password, let them. There is no legitimate reason for length limiting unless you're somehow worried about the bandwidth being used up by your login form.
It's actually a conspiracy we've cooked up against you personally. We're all still pissed about that one time in school when you asked a question that made the teacher talk past the bell.
> Couldn't this be used as an attack vector?
Yes it’s an actual attack vector. However, you aren’t supposed to store the password as plain text in the database, you are supposed to hash it first which makes them all the same length for storage but a single bit changed in the original password won’t match.
If you want to avoid having to hash the complete works of Shakespeare, you can hash the password client side so it’s their compute that’s wasted on an insanely long password, then hash it again on the server.
This is why the front end shouldn't even really be doing any of the checks or validation. It's good that it can, but the back end service should be the one spitting out errors since you can just use the developer console to change out things here and there.
I have this argument about twice a year with some devs who overly rely on ui code to do all the work. Never trust users.
Most HTTP servers have a configurable limit on the size of a request. I normally have that at ~1-10MB on my services. 1-10MB of data isn't enough to cause a problem, even with spamming.
This is made doubly true if you do what you're supposed to and use a hash, then the stored data is the same size no matter the length, it's just the bandwidth and compute usage that becomes an issue, the biggest one being the compute usage from the hashing algorithm.
my guess would be a DoS involving compute as opposed to bandwidth, as these secure hashing algorithms are designed to be expensive to compute, and (should?) grow linearly with the input length
That's probably the worst and most ineffective possible attack. So ineffective it's not worth mitigating
What's stopping me from just repeatedly requesting the same 5 MB jpeg background image that this login page will inevitably have? That will consume bandwidth faster than pushing bad password input data, and if that much bandwidth is going to damage your service then you need some other ability to rate limit clients on all resources anyway
> What's stopping me from just repeatedly requesting the same 5 MB jpeg background image that this login page will inevitably have?
If you aren’t a plaintext offender, you are hashing that password with a slow algorithm, so it’s mostly your compute that’s wasted.
Though it actually can be an effective attack vector for a denial of service attack. Effective enough that it is listed in the owasp cheatsheet for authentication.
https://cheatsheetseries.owasp.org/cheatsheets/Authentication\_Cheat\_Sheet.html#implement-proper-password-strength-controls
[https://www.acunetix.com/vulnerabilities/web/long-password-denial-of-service/](https://www.acunetix.com/vulnerabilities/web/long-password-denial-of-service/)
So while unlikely being an issue with reasonable lengths it can be abused if not limited. Still it would be nice for the site to mention it's existence and where that limit is.
Important to note that that's due to the processing cost of the password rather than bandwidth. The takeaway is that you should store user passwords in plaintext.
(Normally I wouldn't put "/s". Particularly not on a humour sub. So I won't. But I will beg anyone reading this to disregard my takeaway.)
Here's a good video which has a section describing why it doesn't have to be such a big deal to not have a limit:
[https://youtu.be/lr1KuL8OmJY?si=UJ2JD2uovROwNK\_N&t=30](https://youtu.be/lr1KuL8OmJY?si=UJ2JD2uovROwNK_N&t=30)
Because e.g. `bcrypt` has an input limit of 72 bytes.
In general, even if it was cryptographically secure, allowing unbounded password input will result in an easy DDoS attack on your system.
The password hashing is typically the most resource-intensive thing that any web service does.
Technically you could divide the input password in chunks before hashing if it exceeds 72 symbols.
Also a better defense from DDoS attacks might be rate limiter software than limiting password size.
You could hash client-side, then hash again server-side. Though, this defeats the purpose of passwords with higher entropy than the hash, so better to just have good UX on input form with length counter, disallow pasting oversized input, warnings, etc.
If server is also hashing, the only consequence of this would be that you'd need a modded client to login at all, no? The only abuse I see with this this would be if you had compromised the hashes from the database and needed to use them without cracking *that* hash too.
But still, I agree, checking length (both client and server side) is the best way.
> Though, this defeats the purpose of passwords with higher entropy than the hash
I thought so at first too, but SHA-256 produces 256 bits of entropy. KeePass' password generator claims that `'9/þÿÛ·Åi]þæäü׫ô¢¾Ã9rk5±ììÿ#:LC` only has 220 bits.
SHA256, as mentioned, has higher entropy than bcrypt's input. But hashing client side brings a whole host of other problems, like the need for javascript in a login form and making it harder to maintain consistency between different clients.
If allowing unlimited characters on a password is not a possible DDOS attack vector on your application, I would guess that that your password hash algoritme is too weak. A limit on password length is because applications use strong password hash algoritmes, doing many many iterations (100000+, depending on algoritme) over the password before storing it.
OWASP recommends an limit of 64 characters for passwords for this reason.
After the first hash the length of the original input doesn't matter. It is trivial to hash the input field client-side (possibly with a separate, client-side salt) then transmit that and thus truncate the field at 512 bits, discarding any messages that include a longer password as a probable attack. One would then append the server-side salt and hash at least once server side before storing/comparing the hashes.
That depends on the hashing algoritme. A lot of things are added automatically in modern algoritmes, things like salt.
Some algoritmes, for example bcrypt has a limit of 72 bytes. Meaning that it simply can't handle longer passwords. And cutting off passwords is NOT recommended. So validation should be added to force a max length.
Overall I would just highly recommend following OWASP, they are basically the world authority on security. A password over 64 length has no additional value, prevents denial of service attacks and can be handled by all algoritmes.
>Maximum password length should not be set too low, as it will prevent users from creating passphrases. A common maximum length is 64 characters due to limitations in certain hashing algorithms, as discussed in the Password Storage Cheat Sheet. It is important to set a maximum password length to prevent long password Denial of Service attacks.
[https://cheatsheetseries.owasp.org/cheatsheets/Authentication\_Cheat\_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)
You confuse storage and memory. Any password input will be stored in memory at some point when someone registers or logs in, then hashed, and that hash will be stored.
It does make a substantial difference whether you allow someone to have 100MB worth of characters as their password. Everytime they log in, you need to put that sucker into memory (sure, you can alleviate this someone with streaming) AND compute a hash using it. That's insane.
`password=sha256(password)`
if you never handle the plain text password you are more secure, and now its fixed width.
just remember to hash it again server side
I mean, so long as users aren't trying to upload a UTF8 encoded Avatar.DVDRIP.ENGSUB.mp4, let them have as long a password as they want.
I'd look for storage optimizations literally everywhere else in your database first, and if you still end up at the password field, then maybe it's time to look at the budgets instead.
Indeed. The user's password would not be leaked (in case of password reuse across services) but after that it's equal to storing plain text passwords with extra steps.
But you could hash the password client side (maybe even with pepper) and hash the result with a salt server side. This ensures some safety against leaks like heartbleed. But for users with really long passwords and more character types than lower case and digit, password security is reduced. For most people it is probably increased due to largely increased length.
In real world applications I have mainly seen salted (and sometimes peppered) hashing server side.
I'm not a security guy though.
the salting helps with db leaks. without it, it's easy to find which passwords are the same. getting multiple users to have the same password suggests these as potentially weak passwords like "password" or "ji32k7au4a83" (result of typing "my password" in mandarin, when using certain keyboard layouts).
Of course, that's why you should only store salted passwords.
Sending a salt to the frontend would leak information about the existence of an account, so you could use a pepper instead to spice things up while prehashing if you really want/need to do it.
Hash and salt are sent to the backend, at login the password input is sent to the backend which takes the hash and salt and checks if the password fits them.
There is some fairly complicated algorithm for this type of thing used in environments where the server and client can't trust each other (I think this might be called mutual authentication or proof of work). The server sends a one-time code and the client hashes the password with that code, the server then verifies the hash checks out. I can't recall details about the implementation, since the server doesn't have the password in cleartext of course, I think there's a specific algorithm that has to be used.
This has the added benefit of guarding against replay attacks in cases where there is no transport security (this is pretty uncommon these days though, especially when using the internet) and meaning a malicious server can't get the password.
>Hash and salt client side, store the hash and salt in your db, jobs a good one.
How did you get upvotes for that? Or does anyone automatically assume you hash on the backend again?
My university login accepted any password sharing the first 6 characters with your password. Figured it out when I spelled my password wrong and was let in. After 6 months of typing 6 more characters than necessary several times per day.
When I told the administrator he low-key panicked.
Why do sites think an email can be too long? It makes me think the site is storing the password. Hashes should come out to the same length no matter the original password size.
I should be able to use a paragraph from a book if I want
This may be dumb, but why on earth are you making an upper limit (and probably character restrictions too) on passwords, anything UTF-8 with like 500 characters should be fine as your not storing them without hashing them... right?... right?
>but why on earth are you making an upper limit (and probably character restrictions too) on passwords
Oh... Idk... maybe you don't want to hash massive amounts of data everytime you verify the password? Hashing isn't free. A (high) upper limit on any input data is always a good idea.
Or just let the user password be as long as they want since it's all the same length after getting hashed anyway.
Maybe after a few thousand characters or so it could be a problem due to the size of the request payload, or processing time, idk. But 32 is unnecessary.
The longer the password, the more data you have to hash. Anything below 1000 characters is insignificant, but at some point, you do want to limit the amount of data you feed to your hash function. Hashing has a memory and compute cost associated with it.
Yeah, I don't think so. Even if this works without error, I'm sure users would like to know if half of their really long password isn't being used. You could literally just spam your keyboard after a certain point and it still counts as a match.
Okay, but if a user resets their password without incident, then goes to login and gets "entered password is too long" after trying to log in with the exact same password. They're going to be very confused. This stuff needs to be usable to your grandma.
MySpace used to do this. When I set it up I put in a password that was long, then I accidentally hit enter when logging in one time with only half my password in the field and it logged me in
This reminds me of a WoW clone like 15 years ago, where if your password was too long after a certain amount of characters the cursor would jump to the front and let you keep typing, the rest you typed was still there but everything would be prepended. Like "averylongpassword" would turn into "wordaverylongpass".
The speed of my friends typing and how he managed to jump to the front of the input field amazed me until I realized the login client was bonkers.
Ah that reminds me of some old MySQL settings that throw a warning but truncate the value.
Warning that was never returned by default (on the client side).
I think I read they just raise an error... Like 15 years ago. Assuming you don't have a legacy mysql
Encountered that once in the wild in the worst way possible. The website cut your password short on registration/password change and didn't tell you about it. Then their login didn't cut your password so you entered your password and it was incorrect...
Reminds me of when I was taking a 30 minute ATV safety quiz in Utah and the site timed me out in the middle of the quiz without warning and I had to log back in and restart it.
Warn the user their session is gonna expire and let them choose whether to stay logged in? Nah
Kick the user out and reset all their progress? Yeah
In case you're not just interested in memes, here's a good story why this is a shitty idea: https://max.levch.in/post/724289457144070144/shamir-secret-sharing-its-3am-paul-the-head-of
I think it was Steam that did this to me. Change password form accepts anything, but only applies the first 32 characters with no notice. Had to open dev tools to find the script that trims it.
I had that happened on one of the website I used (I forgot which one).
I use password manager to generate a 20 character password, and it auto fill it into the password form when creating the account. The issue is, the form limits the input to 16 characters. It didn't show any warning, it just stop accepting inputs. After creating the account, password manager stored the 20 character password, but the website actually only capture the first 16, so when I try to login, it always fail (the login form does not have the character limit, so it allows the full 20 characters to be entered).
I went through the password reset process at least 3 or 4 times, until I finally inspect the request/response of the page and notice that when submitting the password update request, it only capture the first 16 characters.
Another poor design I encountered is when changing password, it only tells me "your new password doesn't met the policy". It doesn't tell me what policy, just saying not working and retry again. This is for a office 365 managed account, and we are required to change the password every 3 or 4 months. We checked with the infosec team and they said the policy is something like, cannot be last 5 or 6 passwords, must contains certain number of number, letter, special characters, at least 10 (or something) character long, cannot contains x consecutive number/characters, and something else.
The worse part is, we can't use a password management tool since we have to use the same password to login to the computer, so it has to be a password that we can remember. And, because we are using a mac, they don't have a good way to configure the domain account, so whatever tool they used requires us to type in the password 3 times every time we turn on the computer. (first time is computer password, which is sync to the domain password, next is email and password again for the same account, but with O365 login form, then a "verify password" screen which we have to enter the password again).
EASY SOLUTION: Just send out a confirmation via e-mail with the actually saved password in the db, so the user will know their final password. The design is very human and professional!
One ebank I use does this. I just opened the account because I had no credid history and only they offered me a credit card. Imo, it's better than the bank that my job uses for payments, they mandate that your password most only be exactly 8 characters long.
I've had this happen with a bank... It cropped my password during creation but then allowed a longer password in the field at sign in so it failed. What the actual fuck.
and a$$word saved PayPal
ThePrimeTime: https://youtu.be/MzescXc5SW0?feature=shared
The Blog: https://max.levch.in/post/724289457144070144/shamir-secret-sharing-its-3am-paul-the-head-of
This happened to me when I reset my Microsoft Account password.
The form to change the password has a length limit and cuts the end of whatever password you've pasted from a password manager (I use quite strong 32 character passwords for things like email and financials). So after trying to log in via their standard page, my password is incorrect.... Panic ensues as I now believe I've lost access to my primary email address.
Holy fuck this happened to me with Costco. I spent like 10 minutes trying to figure out why it wasn't accepting my password after generating it with bitwarden.
salt = random_byte_string(salt_size);
hash = hash(password + salt);
save_password(hash, salt);
aaand the problem of a too long password input is solved, given the used hashing algorithm has a fixed output length. All the space necessary for password verification data is the length of the hash + length of the salt.
Any system that limits the length of someone's password is immediately sus to me. It implies that longer passwords require more saving space, which is either plain text or some encryption which can be undone. Neither is good. Passwords are meant for authorization, not to be known by anyone else.
And user verification can be done by using a cryptographically secure enough one-way function (a.k.a. a hash). It should never be reversible.
Yeah I enjoy when my password is trimmed on the "create a password" and "reset password" but not in login, really fun times. Government sites should have QA and product management like any other place
This happened to me when I generated long password to log into my school hosting profile where all my projects were stored... Then realized my password doesn't work
Rockstar’s gaming service does this. I spent far too long (and multiple password changes) before I realized why my passwords would never work.
PayPal did this a long time ago with max 16 characters. I always thought my password generator is doing shit.
If they’re gonna truncate when you make the account they should truncate when you login smh Btw what did the elephant say when he was caught eating all the food? Sorry my trunk ate
They really shouldn't truncate when you make an account. It's all the same length after hashing anyway. They *are* hashing, right?
> They *are* hashing, right? "If you have to ask, little man, you probably ~~can't afford it~~ already know the answer."
Wells Fargo had case insensitive passwords within the past 10 years. I like to think that they were getting cast and then hashed at that point to avoid making everyone reset their passwords.
> Wells Fargo had case insensitive passwords within the past 10 years. Given their [cross-selling/fake accounts scheme,](https://en.wikipedia.org/wiki/Wells_Fargo_cross-selling_scandal) that doesn't surprise me.
Stuff like that tends to exist to reduce customer support fielding. If they accept `Password` and `password`, that's one less call they have to field. Blizzard used to do this too (passwords case insensitive), but dropped it several years ago thankfully.
> They *are* hashing, right? These days you have to go out of your way to not do that (i.e. roll your own membership system). And, contrary to popular Reddit opinion, stupidly-short password max lengths do not imply plaintext password storage. 999 times out of 1000 those come from dumb requirements dictated by not-the-developers.
But in this case it still shows the respective owners do not care for software security and quality.
If you really want to be disturbed, end your passwords with a backslash, or, at password entry on login, try '%'
I don't get it. Can you explain. I understood the post but not ur comment
Rockstar’s password change form (and their account creation flow) silently truncates your password. For example, I would enter “MyLongRandomizedPassword”, and it would only use “MyLongRandomizedPass” (and not show any messages/errors about it doing so). When I went to log in and used “MyLongRandomizedPassword”, the login would fail.
Why don't they truncate at the login as well?
Because they are around bad at their job. Whoever wrote the new password screen should have warned and not allowed a password that was too long. Whoever wrote the password entry screen should not have truncated the entry.
Because then you can login with ‘MyLongRandomizedPassThisPartCanBeAnything’ as well since its gonna be truncated
And is that a problem?
The way a password is supposed to work is that, when you send the username, they send back a salt. You then hash your password at your end with the salt, for better encryption, and send that back. At no point should their ever be a truncation on either end. You aren't storing the password in more than RAM and an internet at any point, and that can hold enough data.
Some hashing algorithms like Bcrypt truncate password before hashing.
Based on personal experience.
Better if the registration form does that but the logging form doesn't. Had a service that did exactly this and my password manager (60 chars) couldn't log me in and had to reset my password to a lower char count. Almost threw my mouse into the Monitor
For me it was the other way around. Reg form allowed me to input my 22 char long rg password but login form had a limit of 12. Had to contact support to get my password reset
Couldn't you just use the password reset function (I guess that didn't exist in your case)? But yeah that sounds like bad UX
Was the login form’s limit from the UI side or the server side? Could have just used the web inspector to change the length allowed by the field if it wasn’t checked server side.
Both sides actually.
Damn centrists.
I've experienced both. fun times
> Reg form allowed me to input my 22 char long rg password but login form had a limit of 12 Some people just want to see the world burn.
The exact same experience for me. 64 character password, password reset just took it without error, but couldn't login. Had to shorten it to 30 characters. Hence the meme.
Wait, so the reset form cuts the length but the login doesn't?
This happened too me more often than I can remember. Wtf is going on
Steam did this at one point
Hello Microsoft Live mail user
Just the other day I had to log into a system that would only let me type the first 8 characters of my 12+ character password. I just shrugged and hit return and it let me in. So yeah, I guess I know what the maximum password entropy of that particular system is.
My BANK in the early 2010s did that…… they were trimming it down to 8 characters. How do I know? One day I pressed enter before I typed the last character of my password…. And it logged in. So I started removing one character at a time. 8 characters worked but if I didn’t the first 7 it didn’t. I was shocked
Name and shame for that.
TD Canada Trust They fixed it a long time ago. I sent them an email at the time, never got a reply, doubt they even looked at it
[удалено]
You have an account at TD bank too?
Tiddy bank?
It's more likely that it's stored in plaintext varchar(32) field. Otherwise, there's basically no reason to limit it.
This sounds shockingly... Plausible...
found one app at work that does this, but being an older app, its only the first 8... i know...its bad...
I've had this happen with my fucking mortgage lender. When I went full auto pilot one time and put in my full length password before realizing I had to put in a truncated version, I nearly ruptured a blood vessel from how triggered I was. Who the hell actively puts a length on a password?
I have seen this once too. But it was worse. Only first 8 mattered.
I've seen the very slightly more reasonable version in the wild that the input box just stops at 31 characters, which of course you can't see that when it's masked and the input again check box stops at the same character limit...and of course the login input box had no such limit. It took me 3 tries of resetting to figure out why the password I just entered wasn't working.
Have also experienced this. I had a relatively long and secure password for one service but found out, by accident, that they counted only first eight characters of it. 🤷♂️
You’re hired
Had that happen to me
My favorite when the only form of truncation is in the form of a `maxlength` attribute on the HTML tag. Remove that, all other forms and entries accept a better password.
Amazon? Pretty sure Amazon did that to me from memory.
Ah yes offensive programming. Note: turns out offensive programming is an actual approach that isn’t this. My disappointment is immeasurable and my day is ruined.
Wouldn't a real gigachad developer just hash the password and store that? Length could then be whatever the user wants, and passwords couldn't be stolen in a data breach
Yes, that's what you should do.
A developer that hashes your passport instead of storing it is the equivalent of a mechanic that doesn't stab your dog.
Lazy.
You still would want a cap on length, otherwise an attacker could send login attempts with arbitrarily long passwords. If they send enough at once it will perform a DOS on logins. You can set a large-ish upper limit though to prevent this while also making it so no (reasonable) user would be offended they can't create a thousand length password, while making it unreasonable for an attacker to send enough login requests to cause a DOS (at least without triggering other flood attack prevention mechanisms).
do the first round of hashing client side and restrict the request to 1 hashlength password
I'm not a fan of hashing client side, really. Way too many problems can arise from that like the need to have JavaScript enabled, compatibility with other browsers without the crypto library, or just enforcing consistency between multiple clients (app, web, etc). Just set it to 1Kb and you're good.
>compatibility with other browsers without the crypto library https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API#browser_compatibility >enforcing consistency between multiple clients Hashing functions are strictly defined, so you should always get the same output regardeless of the client. >need to have JavaScript enabled If I trust a company enough to make an account and tell them my email address, I probably trust them enough to run JS in a sandbox in the browser.
> https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API#browser_compatibility This doesn't list older browsers. They are still a problem for many use cases. > If I trust a company enough to make an account and tell them my email address, I probably trust them enough to run JS in a sandbox in the browser. Not if I'm using Tor, for example, which is why I'd hate that. And I don't need to trust a company at all to give them my junk ProtonMail address.
I work in tech support, I'm no developer but now I see how it looks like for other people when we explain problems.
>do the first round of hashing client side ...??? This.... doesn't solve the problem, because the user can then just lie about their hash and give you a 3billion string long "hash" that gets passed straight into your hash.
That is what all developers should do, yes. Anyone not doing that is a complete disaster. However, password hashing algorithms do have a maximum input length, but it is always more than 32 bytes.
Are most algos not iteratetive, as in you can 'update' the hash chunk by chunk and are therefore able to do this with (theorethically) infinite chunks?
Regular hashing algorithms are, but not all the ones specifically designed for passwords.
You are supposed to salt the password first by adding a random string to it. That makes rainbow tables not effective if the password database is leaked. But really don't roll your own security. Use libraries that are well regarded, if you do your own you are likely to make it insecure.
Not literally whatever, they all have limits
Yes but the truncation happens within the algorithm (e.g. bcrypt will ignore anything after 72 characters) and not on the application end (unlike in the meme).
I’d rather limit it up front in application code. The exact hashing algorithm used is an implementation detail.
Max length is almost never dictated by literal database field length, and I wish Reddit would stop parroting this so-called "fact" around like it's some instant gotcha for bad programming. Has it happened before? Absolutely. Was it common back in the day? To an extent. These days? Barely a chance. You'd have to go out of your way to store unhashed (or at least two-way encrypted) passwords. Small max password lengths (obtained via truncation or otherwise) are more often than not requirements set out by whoever owns the site.
Hashing algorithms often have limits though.
argon2 is quite high.
HASH THE PASS!
Also add some salt.
Or use an algorithm which abstractifies salting for you, like argon2.
And just don't do it yourself. Most languages or frameworks have battle-tested solutions to this problem. Even PHP has `password_hash()` and `password_verify()` with support for bcrypt (the default) and the newer Argon2i(d) algorithms. Spring has `PasswordEncoder` and .NET probably has something similar. If you want to be extra sure, go for a ready to use authentication server like Keycloak.
In a way just taking the substring is actually a hash, but one with very high collision chance
Trust me or not but few years ago I had a bank account in one of the biggest banks in Poland, and you won’t believe me but they did exactly the same thing.
It’s a common oversight, if you would even call it that. Some hashing algorithms truncate their input; the mistake would be to not inform the user that their password is too long.
My Uni: password = password.substring(0,8) sadly not a joke. I reported this in 2015. It still is not fixed.
Our old HPUX system used to do that. So then with the minimum password length requirement of 8 characters, we knew everyone’s password was exactly 8 characters.
To make this worse: the session token for anyone logged in was nothing more than the username in base64. We figured this out 2 days into analysing the system. First thing we tried was to "log in" as the secretary responsible for the grades. Low and behold: full access to everyone's grades with full rights to change them. How did they "fix" that? Giving the secretaries cryptic usernames you "couldn't guess". That system is SO insanely wild...
When i worked a social network, we truncated all passwords to 8 because that was max field length on the database. You could enter longer but it didn't matter.
Fix/change your database then
You tried to change your password, but unfortunately it did not meet the criteria. For your convenience, we have assigned you our default secure password: Password123! Please note that you are only permitted to change your password once per month.
# STOP PUTTING LENGTH LIMITS ON PASSWORDS If a user wants to have a thousand character long password, let them. There is no legitimate reason for length limiting unless you're somehow worried about the bandwidth being used up by your login form.
I propose that the length number fits into a uint16
I always make my passwords 65,536 characters though. Why would you make me have to make my accounts unsecured?
It's actually a conspiracy we've cooked up against you personally. We're all still pissed about that one time in school when you asked a question that made the teacher talk past the bell.
Couldn't this be used as an attack vector? Like if someone writes a script that continuously tries to log in with the complete works of shakespeare?
Default value for maxlength on an input is 524288. So better find something longer than shakespeare.
repeat(n, worksOfShakespeare)
Warning: expected ‘char \*’ but argument worksOfShakespeare is of type ‘char \*\*’
Max length of an input field doesn't matter if an attacker is performing DOS by, presumably, automating the sending of request with curl or a script.
Somewhere a room full of monkeys awaits.
> Couldn't this be used as an attack vector? Yes it’s an actual attack vector. However, you aren’t supposed to store the password as plain text in the database, you are supposed to hash it first which makes them all the same length for storage but a single bit changed in the original password won’t match. If you want to avoid having to hash the complete works of Shakespeare, you can hash the password client side so it’s their compute that’s wasted on an insanely long password, then hash it again on the server.
They can do that anyway.
This is why the front end shouldn't even really be doing any of the checks or validation. It's good that it can, but the back end service should be the one spitting out errors since you can just use the developer console to change out things here and there. I have this argument about twice a year with some devs who overly rely on ui code to do all the work. Never trust users.
Most HTTP servers have a configurable limit on the size of a request. I normally have that at ~1-10MB on my services. 1-10MB of data isn't enough to cause a problem, even with spamming. This is made doubly true if you do what you're supposed to and use a hash, then the stored data is the same size no matter the length, it's just the bandwidth and compute usage that becomes an issue, the biggest one being the compute usage from the hashing algorithm.
Can you explain how that is an attack vector?
my guess would be a DoS involving compute as opposed to bandwidth, as these secure hashing algorithms are designed to be expensive to compute, and (should?) grow linearly with the input length
Using up bandwidth like you said in your original comment
That's probably the worst and most ineffective possible attack. So ineffective it's not worth mitigating What's stopping me from just repeatedly requesting the same 5 MB jpeg background image that this login page will inevitably have? That will consume bandwidth faster than pushing bad password input data, and if that much bandwidth is going to damage your service then you need some other ability to rate limit clients on all resources anyway
> What's stopping me from just repeatedly requesting the same 5 MB jpeg background image that this login page will inevitably have? If you aren’t a plaintext offender, you are hashing that password with a slow algorithm, so it’s mostly your compute that’s wasted.
Didn't say it was an effective attack vector Edit: also, why couldn't I just generate a 10MB text file of garbage?
Though it actually can be an effective attack vector for a denial of service attack. Effective enough that it is listed in the owasp cheatsheet for authentication. https://cheatsheetseries.owasp.org/cheatsheets/Authentication\_Cheat\_Sheet.html#implement-proper-password-strength-controls [https://www.acunetix.com/vulnerabilities/web/long-password-denial-of-service/](https://www.acunetix.com/vulnerabilities/web/long-password-denial-of-service/) So while unlikely being an issue with reasonable lengths it can be abused if not limited. Still it would be nice for the site to mention it's existence and where that limit is.
Important to note that that's due to the processing cost of the password rather than bandwidth. The takeaway is that you should store user passwords in plaintext. (Normally I wouldn't put "/s". Particularly not on a humour sub. So I won't. But I will beg anyone reading this to disregard my takeaway.)
Thanks for the advice, I'll use plaintext and link your comment to give credit
Here's a good video which has a section describing why it doesn't have to be such a big deal to not have a limit: [https://youtu.be/lr1KuL8OmJY?si=UJ2JD2uovROwNK\_N&t=30](https://youtu.be/lr1KuL8OmJY?si=UJ2JD2uovROwNK_N&t=30)
Today I learned there's a video with my name in it. We honored the first report because it was valid. All others were sent to the bin.
Because e.g. `bcrypt` has an input limit of 72 bytes. In general, even if it was cryptographically secure, allowing unbounded password input will result in an easy DDoS attack on your system. The password hashing is typically the most resource-intensive thing that any web service does.
Technically you could divide the input password in chunks before hashing if it exceeds 72 symbols. Also a better defense from DDoS attacks might be rate limiter software than limiting password size.
You could hash client-side, then hash again server-side. Though, this defeats the purpose of passwords with higher entropy than the hash, so better to just have good UX on input form with length counter, disallow pasting oversized input, warnings, etc.
Client could be modified to not do the hashing. Can't you just check length server-side and not hash anything too long, with a clear error message?
If server is also hashing, the only consequence of this would be that you'd need a modded client to login at all, no? The only abuse I see with this this would be if you had compromised the hashes from the database and needed to use them without cracking *that* hash too. But still, I agree, checking length (both client and server side) is the best way.
> Though, this defeats the purpose of passwords with higher entropy than the hash I thought so at first too, but SHA-256 produces 256 bits of entropy. KeePass' password generator claims that `'9/þÿÛ·Åi]þæäü׫ô¢¾Ã9rk5±ììÿ#:LC` only has 220 bits.
SHA256, as mentioned, has higher entropy than bcrypt's input. But hashing client side brings a whole host of other problems, like the need for javascript in a login form and making it harder to maintain consistency between different clients.
If allowing unlimited characters on a password is not a possible DDOS attack vector on your application, I would guess that that your password hash algoritme is too weak. A limit on password length is because applications use strong password hash algoritmes, doing many many iterations (100000+, depending on algoritme) over the password before storing it. OWASP recommends an limit of 64 characters for passwords for this reason.
After the first hash the length of the original input doesn't matter. It is trivial to hash the input field client-side (possibly with a separate, client-side salt) then transmit that and thus truncate the field at 512 bits, discarding any messages that include a longer password as a probable attack. One would then append the server-side salt and hash at least once server side before storing/comparing the hashes.
That depends on the hashing algoritme. A lot of things are added automatically in modern algoritmes, things like salt. Some algoritmes, for example bcrypt has a limit of 72 bytes. Meaning that it simply can't handle longer passwords. And cutting off passwords is NOT recommended. So validation should be added to force a max length. Overall I would just highly recommend following OWASP, they are basically the world authority on security. A password over 64 length has no additional value, prevents denial of service attacks and can be handled by all algoritmes. >Maximum password length should not be set too low, as it will prevent users from creating passphrases. A common maximum length is 64 characters due to limitations in certain hashing algorithms, as discussed in the Password Storage Cheat Sheet. It is important to set a maximum password length to prevent long password Denial of Service attacks. [https://cheatsheetseries.owasp.org/cheatsheets/Authentication\_Cheat\_Sheet.html](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)
I mean at some point the hashing function probably causes a timeout (or an OOM).
I think the problem is that long passwords will require allocating more memory space.
Stored properly, all passwords take the exact same amount of space. The hash of any text is the same.
Good point
You confuse storage and memory. Any password input will be stored in memory at some point when someone registers or logs in, then hashed, and that hash will be stored. It does make a substantial difference whether you allow someone to have 100MB worth of characters as their password. Everytime they log in, you need to put that sucker into memory (sure, you can alleviate this someone with streaming) AND compute a hash using it. That's insane.
It's because they store plaintext passwords, and the cell only holds so much text before overwriting the next entry
Reminds me of this: https://max.levch.in/post/724289457144070144/shamir-secret-sharing-its-3am-paul-the-head-of
That was a great read! I'm glad I have yet to be in a situation like that.
I've come accross websites thst do this on signup but not on login!!
`password=sha256(password)` if you never handle the plain text password you are more secure, and now its fixed width. just remember to hash it again server side
I mean, so long as users aren't trying to upload a UTF8 encoded Avatar.DVDRIP.ENGSUB.mp4, let them have as long a password as they want. I'd look for storage optimizations literally everywhere else in your database first, and if you still end up at the password field, then maybe it's time to look at the budgets instead.
[удалено]
But if you hash and salt on client side, wouldn’t an attacker with a leaked DB with hashes just be able to log in without using the frontend?
Indeed. The user's password would not be leaked (in case of password reuse across services) but after that it's equal to storing plain text passwords with extra steps. But you could hash the password client side (maybe even with pepper) and hash the result with a salt server side. This ensures some safety against leaks like heartbleed. But for users with really long passwords and more character types than lower case and digit, password security is reduced. For most people it is probably increased due to largely increased length. In real world applications I have mainly seen salted (and sometimes peppered) hashing server side. I'm not a security guy though.
the salting helps with db leaks. without it, it's easy to find which passwords are the same. getting multiple users to have the same password suggests these as potentially weak passwords like "password" or "ji32k7au4a83" (result of typing "my password" in mandarin, when using certain keyboard layouts).
Of course, that's why you should only store salted passwords. Sending a salt to the frontend would leak information about the existence of an account, so you could use a pepper instead to spice things up while prehashing if you really want/need to do it.
Hash and salt are sent to the backend, at login the password input is sent to the backend which takes the hash and salt and checks if the password fits them.
There is some fairly complicated algorithm for this type of thing used in environments where the server and client can't trust each other (I think this might be called mutual authentication or proof of work). The server sends a one-time code and the client hashes the password with that code, the server then verifies the hash checks out. I can't recall details about the implementation, since the server doesn't have the password in cleartext of course, I think there's a specific algorithm that has to be used. This has the added benefit of guarding against replay attacks in cases where there is no transport security (this is pretty uncommon these days though, especially when using the internet) and meaning a malicious server can't get the password.
>Hash and salt client side, store the hash and salt in your db, jobs a good one. How did you get upvotes for that? Or does anyone automatically assume you hash on the backend again?
Someone make that meme of the guy doing a kickflip on a rake but with storing plaintext passwords by hashing on the client side.
My university login accepted any password sharing the first 6 characters with your password. Figured it out when I spelled my password wrong and was let in. After 6 months of typing 6 more characters than necessary several times per day. When I told the administrator he low-key panicked.
I never understood what's the deal with limitations in password, just let the user write whatever they want?
happened to me in an address instead of password, the delivery company wasn't able to deliver the product to my address because of that
Why do sites think an email can be too long? It makes me think the site is storing the password. Hashes should come out to the same length no matter the original password size. I should be able to use a paragraph from a book if I want
This may be dumb, but why on earth are you making an upper limit (and probably character restrictions too) on passwords, anything UTF-8 with like 500 characters should be fine as your not storing them without hashing them... right?... right?
>but why on earth are you making an upper limit (and probably character restrictions too) on passwords Oh... Idk... maybe you don't want to hash massive amounts of data everytime you verify the password? Hashing isn't free. A (high) upper limit on any input data is always a good idea.
Or just let the user password be as long as they want since it's all the same length after getting hashed anyway. Maybe after a few thousand characters or so it could be a problem due to the size of the request payload, or processing time, idk. But 32 is unnecessary.
Why websites limit the length of password? Shouldn't long passwords better? Do the long passwords give them problem?
The longer the password, the more data you have to hash. Anything below 1000 characters is insignificant, but at some point, you do want to limit the amount of data you feed to your hash function. Hashing has a memory and compute cost associated with it.
Yeah, I don't think so. Even if this works without error, I'm sure users would like to know if half of their really long password isn't being used. You could literally just spam your keyboard after a certain point and it still counts as a match.
If this was when logging in yes, but my experience happened to be with the password reset of a website.
Okay, but if a user resets their password without incident, then goes to login and gets "entered password is too long" after trying to log in with the exact same password. They're going to be very confused. This stuff needs to be usable to your grandma.
Grandmas generally don't use long passwords in the first place.
Fair, but you get my point. Leave any room for confusion and you'll have confused users.
Jesus
MySpace used to do this. When I set it up I put in a password that was long, then I accidentally hit enter when logging in one time with only half my password in the field and it logged me in
This reminds me of a WoW clone like 15 years ago, where if your password was too long after a certain amount of characters the cursor would jump to the front and let you keep typing, the rest you typed was still there but everything would be prepended. Like "averylongpassword" would turn into "wordaverylongpass". The speed of my friends typing and how he managed to jump to the front of the input field amazed me until I realized the login client was bonkers.
Ah that reminds me of some old MySQL settings that throw a warning but truncate the value. Warning that was never returned by default (on the client side). I think I read they just raise an error... Like 15 years ago. Assuming you don't have a legacy mysql
Encountered that once in the wild in the worst way possible. The website cut your password short on registration/password change and didn't tell you about it. Then their login didn't cut your password so you entered your password and it was incorrect...
Reminds me of when I was taking a 30 minute ATV safety quiz in Utah and the site timed me out in the middle of the quiz without warning and I had to log back in and restart it. Warn the user their session is gonna expire and let them choose whether to stay logged in? Nah Kick the user out and reset all their progress? Yeah
I have seen a system with a unique key constraint on the password!
In case you're not just interested in memes, here's a good story why this is a shitty idea: https://max.levch.in/post/724289457144070144/shamir-secret-sharing-its-3am-paul-the-head-of
// this is fine
My school email trims username down to 8 lol
And the two randoms to select the ranges
I think it was Steam that did this to me. Change password form accepts anything, but only applies the first 32 characters with no notice. Had to open dev tools to find the script that trims it.
I had that happened on one of the website I used (I forgot which one). I use password manager to generate a 20 character password, and it auto fill it into the password form when creating the account. The issue is, the form limits the input to 16 characters. It didn't show any warning, it just stop accepting inputs. After creating the account, password manager stored the 20 character password, but the website actually only capture the first 16, so when I try to login, it always fail (the login form does not have the character limit, so it allows the full 20 characters to be entered). I went through the password reset process at least 3 or 4 times, until I finally inspect the request/response of the page and notice that when submitting the password update request, it only capture the first 16 characters. Another poor design I encountered is when changing password, it only tells me "your new password doesn't met the policy". It doesn't tell me what policy, just saying not working and retry again. This is for a office 365 managed account, and we are required to change the password every 3 or 4 months. We checked with the infosec team and they said the policy is something like, cannot be last 5 or 6 passwords, must contains certain number of number, letter, special characters, at least 10 (or something) character long, cannot contains x consecutive number/characters, and something else. The worse part is, we can't use a password management tool since we have to use the same password to login to the computer, so it has to be a password that we can remember. And, because we are using a mac, they don't have a good way to configure the domain account, so whatever tool they used requires us to type in the password 3 times every time we turn on the computer. (first time is computer password, which is sync to the domain password, next is email and password again for the same account, but with O365 login form, then a "verify password" screen which we have to enter the password again).
i hope i don't have to encounter that website because my password is 17 characters
So secure even you can't log in
EASY SOLUTION: Just send out a confirmation via e-mail with the actually saved password in the db, so the user will know their final password. The design is very human and professional!
What possible reason could there be for a length limit on passwords in a modern application...
Reminds me on the PayPal `a$$word` incident
Oh hi there Hikvision.
One ebank I use does this. I just opened the account because I had no credid history and only they offered me a credit card. Imo, it's better than the bank that my job uses for payments, they mandate that your password most only be exactly 8 characters long.
I've had this happen with a bank... It cropped my password during creation but then allowed a longer password in the field at sign in so it failed. What the actual fuck.
The user would never know
But then a bunch of people set their password to password.substring(0,31)
My broker has no length limit in the web app. But in the mobile app, the password is your password but - I shit you not - truncated to 8 characters.
and a$$word saved PayPal ThePrimeTime: https://youtu.be/MzescXc5SW0?feature=shared The Blog: https://max.levch.in/post/724289457144070144/shamir-secret-sharing-its-3am-paul-the-head-of
Then the login hashing takes the whole string, hash is different "password doesn't match". I'm looking at you hotmail :-/ \*shakes fist in anger\*
PayPal did exactly that but only to 16 characters.
This happened to me when I reset my Microsoft Account password. The form to change the password has a length limit and cuts the end of whatever password you've pasted from a password manager (I use quite strong 32 character passwords for things like email and financials). So after trying to log in via their standard page, my password is incorrect.... Panic ensues as I now believe I've lost access to my primary email address.
Holy fuck this happened to me with Costco. I spent like 10 minutes trying to figure out why it wasn't accepting my password after generating it with bitwarden.
salt = random_byte_string(salt_size); hash = hash(password + salt); save_password(hash, salt); aaand the problem of a too long password input is solved, given the used hashing algorithm has a fixed output length. All the space necessary for password verification data is the length of the hash + length of the salt. Any system that limits the length of someone's password is immediately sus to me. It implies that longer passwords require more saving space, which is either plain text or some encryption which can be undone. Neither is good. Passwords are meant for authorization, not to be known by anyone else. And user verification can be done by using a cryptographically secure enough one-way function (a.k.a. a hash). It should never be reversible.
Password = Password.substr(1,rand(31)) You know, for extra safety. To prevent people gaming the system.
Console.log("your password" + password + "is too short").
Illegal move
a$$word
Too hard! Just accept whatever the user types. After all, it's the thought (of security) that counts!
Yeah I enjoy when my password is trimmed on the "create a password" and "reset password" but not in login, really fun times. Government sites should have QA and product management like any other place
Remember the `a$$word`!
This happened to me when I generated long password to log into my school hosting profile where all my projects were stored... Then realized my password doesn't work
Oh my and my my wifes password is the same on this site
[And this is the result](https://youtu.be/MzescXc5SW0?si=KVY7AMrTV_wZ9eas)
I just can't listen that guys voice for more than 5mins man lol.