come to think about it.. You don't even need to!
If you dockerize a chrome instance to start an electron app, you can then use it as a miroservice to truncate!
I even has the possibility to inspect the element and actually see what's going on.
From the WHATWG/W3C definitions of the maxlength attribute:
> Constraint validation: If an element has a maximum allowed value length, its dirty value flag is true, its value was last changed by a user edit (as opposed to a change made by a script), and the code-unit length of the element’s value is greater than the element’s maximum allowed value length, then the element is suffering from being too long.
> User agents may prevent the user from causing the element’s value to be set to a value whose code-unit length is greater than the element’s maximum allowed value length.
The key word, I think, is "may" in that user agents do not seem to be obligated to truncate text from what I can find in the standard.
While this does break the expectations from a developer point of view, I think it is perfectly in line with what users expect when they paste text. I think text falling off at the end after a paste with no explanation is more confusing than an the field glowing red with a message "you can only enter X characters here".
The old behaviour famously made people lose access to their PayPal account where the login form had a different maxlength as the registration form and where the password manager had put in a nice, long password. Preventing this sounds like a fine change for me, despite the compatibility break.
Arguably truncating the text is against the specification as it only specifies that the user agent may prevent the user from going beyond the max-length, not that it may do arbitrary stuff to make the text fit.
I also hope it will make at least some developers realise that client-side validation is a bad idea.
I'd say the fact that it says that the user agent may, not must, truncate the text is a sign that this behaviour should not be expected. Failing the HTML5 validation is also perfectly reasonable. If people are building web pages right, this change will have little impact.
>If the input element has a maximum allowed value length, then the length of the value of the element's value attribute must be equal to or less than the element's maximum allowed value length.
I'm a little bit confused, Which one should we follow?
> A control's value is its internal state. As such, it might not match the user's current input.
The example goes on to describe cases where a browser might remove padding spaces from a field, or refuse to register (as a value) a text entry in a numeric field.
It's fairly common to copy a large amount of text and drop it into an input with length restrictions. For instance, I do it often when I submit HN titles. For regular text, it's a much better UX to be able to paste the whole thing then edit it down to meet the restrictions than to paste and have it auto-truncated.
When it comes to password inputs, where you can't necessarily see what you're pasting, it's extremely important than the user knows when truncation occurs. But could that be achieved while still respecting maxlength? Yes, I think it would be decent UX to alert the user when they attempt to paste text that exceeds the maxlength, without actually completing the paste. That way, the input remains empty so there's no confusion about whether the full password or a truncated password has been entered, and the user can take appropriate action.
You should just let the password field have kilobytes of data. Throw a warning, but it costs you almost nothing. You don’t have to store the data, processing password hashes is designed to take a long time and use a lot of memory (way more than the password of a few KB).
Your web app should also not engage with the password field as much as possible. Don’t make it a component, just leave it a password field. Don’t read it except to immediately send the contents to the server. Bonus points for just having that be a form submission.
- HTML spec allows it; says MAY, not MUST [3]
- Affects only user pastes, not javascript edits
- Affects all input boxes, not just password ones
- New preference editor.truncate_user_pastes can restore old behavior
As a developer, I personally find the inconsistent behavior of maxLength unintuitive and am surprised a potentially-breaking change like this didn't have more discussion (although, the original bug report was open for 4 years). But as a user, I have some empathy for the team's desire to fix "broken" websites (e.g. where the login page has a shorter limit than the account creation page or backend).
As someone whose user agent is Firefox, I’d rather that maxLength didn’t exist at all, and given that it does, my user agent ignoring that seems like the best solution to me.
Now how can we reclaim `onpaste` events? If I'm in an input box and paste text, are there any legit use cases of _blocking_ paste of text in text entry fields?
If you are browsing with Firefox, then yes, you can. Set this variable, "dom.event.clipboardevents.enabled", in about:config to false and websites can no longer block you from pasting into input fields.
This is a welcome change, but what would make it even more awesome is a little red bar at the last character that fits into the maxlength. A semi-common thing I do is paste a long thing of text into an exerpt text area, let it truncate to maxlength and manually tweak the ending. A little red bar to tell me where it would've gotten truncated would make that still possible, while fixing the dangerous behavior with truncating fields.
I have used password-store (pass) to generate passwords and paste them to forms without realizing they were truncated and simultaneously those sites don't have the same maxlength on their login form.
A particular case that I have seen is fields for account numbers that expect X characters, but people are copypasting the numbers from sources where they are represented with extra spaces for readability. (e.g. 1234 5678 instead of 12345678) And when they get to the validation, the last digit(s) have been lost.
At least this behaviour is better than iOS Safari, which will happily send an input field longer than maxlength to the server. You can find a whole bunch of StackOverflow questions about this [1][2]. So if you will need a server side check regardless of what Firefox does. (Of course, you need a server side check anyway, but you need one with proper feedback rather than throwing back an "Unacceptable" http status code).
We’ll, at a certain point CPU consumption from hashing a sufficiently massive pass would be a concern, no? Like, bcrypt is a pretty slow function, although I don’t know how it scales with input length.
Edit: Hunh, apparently bcrypt only handles 72 chars anyways.
You should be doing some fairly expensive hashing if you're storing the password correctly. Maybe not an issue for a 50k char password, but how about a 50 billion char password?
> You should be doing some fairly expensive hashing if you're storing the password correctly
Exactly. You aren't storing those bytes.
> Maybe not an issue for a 50k char password, but how about a 50 billion char password?
We're back to a place where the response to the question is another question, but it just ends up failing to give an answer, opting to just keep throwing out larger and larger numbers. My response: "Yeah, okay. How about it?" Why stop at 50 billion? 99 trillion, let's go there next. Again: why not?
Because 50 billion chars is over 46 GiB of data. There are natural consequences of very large payloads and limits that you're going to reach as a result of those consequences (e.g. being prohibitively expensive for the client to send in the first place, or it will max out the server's connectivity lifetimes for extant requests before the payload can be delivered). If "CPU utilization crosses threshold" is the real reason, then let that be the real reason—and let the safeguards you have in place for handling those problems do their jobs. And if "we cap passwords to X chars" is your safeguard, then you have bigger problems.
> If "CPU utilization crosses threshold" is the real reason, then let that be the real reason—and let the safeguards you have in place for handling those problems do their jobs.
To me, this feels a bit like passing the buck.
If you want to test your backend with 50-billion-character passwords as a safeguard in case things get screwy, that makes sense to me! But, has that test been done? Are you sure?
I see this as analogous to the concept of "defense in depth". Safeguarding against very weird edge-cases which do not provide utility to anyone is a good idea. If you assume the other part of the chain can deal with it, and you're wrong, things blow up. If you assume the worst, all will be well regardless.
Consistency for the user is also important. If your login processing code does more work than your password-setting code, load limits may allow a password to be set that then can’t be used for login. A length limit acts like a fuse, ensuring that under load it’s the thing that breaks first and in a predictable way.
This still requires you to hash the hash on the server, otherwise the hash becomes the password and learning the hash allows you to login. But hashing the hash is actually better anyway because it makes it so that the server never even has the plaintext of the password, which can be dangerous in itself when users use the same password on multiple sites.
This is a backend concern, not a frontend one. The backend shouldn’t naively accept input without making sure the input is within the backend’s limitations.
Client side validation does not replace server side validation, and vice versa. Just because you validate server side doesn’t mean you can’t also do it client side and avoid a round trip.
I guess? But if someone puts in a ten megabyte password they are either suffering a bug or blatantly screwing with you. It's okay to throw a 400 error at them.
Nope. Not reasonable, and likely of no benefit to anyone. That'd be like 50kb... assuming it doesn't cause your hashing algorithm to take a shit causing breakage. 50kb to on one request, sitting pretty much at rest 99.9% of the time, is nothing to even bother with. Most folks should probably spend more time worry about optimizing their own payloads instead of their users [1].
[1] To that point, most people want to spend time on useless optimizations like truncating a password when they should be spending time reducing the size of their images, making sure requests are gzipped, or reducing their obscenely complex front-end bundle. It's just that most of those optimizations which are useful, only make you feel stupid for not implementing them sooner because they're obvious and easy, while truncating a password feels like YOU outsmarted something (when in fact you didn't)
Not allowing a 50k char password is entirely reasonable. For one, a sha256 hash of 50kB would take a good quarter of a second (possibly more, I just ). That's already ridiculous. Some sites also check passwords for dumb things like taking the username and doing 1337-type substitutions, which would (if implemented badly) take even longer.
More importantly though, a 50k character password is barely more secure than a 20 character one, but it gives the user a false sense of security. Passwords are inherently flawed and we shouldn't kid ourselves that just making them longer makes a difference.
If you're in a situation that calls for a 2^400 keyspace, you probably shouldn't be using passwords anyways.
The graph I looked at (that I was supposed to link in parentheses, but apparently failed) comes from [0] and actually shows crypt() performance as a function of key length, comparing different hashing alorigthms. Admittedly, not purely a sha256 benchmark, but possibly even more relevant to passwords. It looks pretty linear to me, so extrapolating to 50kB gives me 0.3625 seconds.
That being said, I just ran a very simple test with just sha256sum and broke 0.3s only at 32MiB, so either crypt() is doing much more than I tought (is salting _that_ expensive?) or I am reading that post completely wrong.
It should give you much more than that, considering that the green (SHA256) graph hits almost 0.1s at just 1000 bytes of input.
>either crypt() is doing much more than I tought (is salting _that_ expensive?)
glibc crypt() is probably doing more than you thought, but it's not salting: in SHA256 mode, various combinations of the key and intermediate hash digests are repeatedly hashed in a certain pattern for 5000 times, although the number of rounds can be changed just like the hashing algorithm. (This is a glibc implementation detail; not all crypt() implementations support extensions like SHA256 mode.)
In general, all general purpose cryptographic hash functions are reasonably fast.
> It's common in practice even if it shouldn't be.
It should be though, the backend should reject overlong passwords, and the frontend should have such limits as well.
Though by "overlong" I mean kbyte range, not 32 character. The point of the limitation is to avoid randos feeding megabytes of data into your KDF and DOSing your server.
> Also many bcrypt implementations truncate input longer than 72 characters.
The alternative would be to error as bcrypt works on 18 words (of 32 bits). You need special handling (pre-hashing with a non-broken cryptographic hash function) to fix this issue.
Also it's 72 bytes not characters. And your pre-hash needs to generate some sort of textual representation (hex, base64, base85, …), as bcrypt will also truncate at the first NUL byte.
> The point of the limitation is to avoid randos feeding megabytes of data into your KDF and DOSing your server.
You shouldn't be using a KDF that takes significantly longer when the password gets bigger. If you make that mistake, even a kilobyte is going to be annoyingly slow. If you don't make that mistake, then even MAX_POST_SIZE passwords won't DOS you.
> You shouldn't be using a KDF that takes significantly longer when the password gets bigger.
Your KDF necessarily takes longer when the password gets longer as it's a hash function and thus O(n).
For typical password sizes (typically under 64 bytes), you're below the hash's blocksize so the effect is nil and you can treat it as a constant but it will start coming into play as the size of the key and thus the number of blocks to feed into the hash increases.
If you're really paranoid about cryptography then reject it. If you're slightly less paranoid then pass it through SHA512 before bcrypting it. Never silently truncate a password.
A year after you leave the job, your team is told to build a new auth backend against the database, using a different bcrypt implementation. They just know to use bcrypt, but not about your truncation hack. The deployment is a success.
Two weeks later, an angry user (the only one with a 100-digit password) complains that they can't log in anymore. The guy is the company's best-paying customer; the boss is furious. The whole team goes on a wild goose chase for two days and nights just to find out what happened, as clearly there's nothing wrong with their code.
A few years later, a former colleague shares the episode on HN. As you read the comments, it dawns on you that the idiot antagonist of the story is you. In this moment, you are enlightened.
The point of the upstream post was that bcrypt implementations often already truncate your passwords to 72 characters.
If you switch to a different bcrypt implementation that does/does not truncate at 72 characters, the server-side truncation keeps all those 73 character passwords working.
If the server-side truncation were not in place, you'd get angry users.
Suppose a user whose first name is Jonathan and whose wife's name is Katherine uses the password "JonathanAndKatherineLU8zWNmkimQanaSdPdqatWJEWR8goyyhdtQeqZOp2+0" and you truncate it to 20 characters.
So potentially even worse. Somebody decides they don't like variable-width encodings and uses UTF-32 and now 72 bytes doesn't even get you 20 code points, only 18.
But it's the same principle no matter where you cut. User thinks they can use an arbitrarily long password, puts a long but low entropy or easily guessable string at the front and makes up for it by having some good entropy at the end, and then you chop off the end.
Because you're misleading the user. Loudly complaining about invalid input is okay, but accepting and silently changing it in a way that affects it properties is not.
If your password is too long to fit in a hash scheme, then it's probably secure to just truncate and match. Unless the user has little entropy in the first part of their password, which i can't see happening.
Many sites have had unreasonable max length limits on passwords, such as 4, 6, 8, or 12 characters. These unreasonably short limits are bad. However, some seem to take this logic to an extreme, suggesting that even much larger limits are detrimental. Once you get up to say 14-16 random characters or 4-5 random words, with proper hashing, there's just no realistic risk of your password being brute forced. Beyond that you're just wasting effort. And someday it's conceivable you'll need to type that password in on a device where you can't install your password manager; what then? So, giving it plenty of margin; say someone wants to type in 10 10-character words, and round up to 127, or even 255 if you like. I'm going to go on record saying there's no reasonable reason to allow password inputs longer than that in 2020. (And there's no real reason to make passwords nearly that long, but also not much gained by restricting them further.)
I welcome responses explaining why passwords of hundreds of characters would ever be necessary or useful.
Most password managers don't even let you generate passwords longer than 50-100 characters anyway.
So long as you're using a password manager that generates unique passwords for every site you visit, there's no real reason to have those generated passwords be particularly long. Ten random characters (with enforced complexity rules) is more than ample for any normal, plausible scenario. If you're a high value individual, you might want to eliminate any doubt and use 12–15 characters. Exceeding that is security masturbation—but also lacks any downside so long as you never have to transcribe it.
Or if you fear worldwide retribution, 20 characters is enough to withstand all compute power on earth suddenly dedicated to the task of cracking your Spotify password.
The only scenario I can imagine where the length of random+unique passwords matters AT ALL is if (1) the website uses a very weak/naive password hash implementation (2) a hacker manages to acquire a copy of your hashed password and (3) the account is of sufficiently high value to justify a large investment in computing resources to brute force the hash. Hitting that trifecta is very unlikely indeed.
I actually ran into a case where the input maxlength on the password field was longer than the maxlength on the "set password" field. When I used my password manager I could login, but when I pasted my password, I couldn't login.
This will probably be helpful. I frequently come across fields which have a tight maxlength where there may or may not be spaces in the field (things like credit card numbers, sort codes, postcodes). When pasting in a version with spaces, this frequently deletes parts of the field which are relevant and required me to delete the spaces and then fill in the result. With this change I would be able to paste it in and then just delete the spaces.
>The form cannot be submitted until the user fixes the error, so the server shall not receive an excessively long text or password
Seems like win/win for everyone. In-spec, less confusing for users, and doesn't change behavior for normal form submissions (JS submitters are clearly opting out of browser safety nets).
They should remove maxlength altogether; it breaks the expected behavior of textboses wherein pressing a key when focus is in a textbox inserts the character corresponding to that key.
Yeah that's the weird thing. They write "for password fields" and then apply it to non-password fields and even multi-line fields. Have you ever seen a multi-line password field?! I understand that people might abuse <textarea> for it but that's definitely not the common thing and just crazy talk. It's an excuse but I don't understand the reason behind this change.
I've been setting maxlength to generous values on my fields in applications since I started coding HTML, if now suddenly I have to revisit everything and add JavaScript magic to check form validity where previously the page was completely free of JS, well, I think I'd frankly refuse where possible and tell people to complain to their faulty implementation.
At the risk of stating the obvious, and sorry if so: doing input length validation client side is very useful for the user's experience, but the server should always validate this too. "... now suddenly I have to revisit everything and add JavaScript magic to check form validity ..." sounds suspiciously like you were relying on client side form validation without server validation, I hope that's not the case. :)
It prevents server-side errors, which I don't handle as gracefully. When the client sends content that it shouldn't have been able to send (i.e. someone tampered with the form) and the server bails out, I don't always bother making it pretty.
I'm well aware of the risks in client-side validation, but indeed, as I see in my job often enough (I'm a security consultant), it's a valid remark that not everyone has taken to heart quite yet so thanks for the comment :)
> The form cannot be submitted until the user fixes the error, so the server shouldn’t receive an excessively long text or password (a server-side validation has to be put in place anyway.) However, this could potentially affect a front-end implementation if it expects the entered text never to exceed maxlength.
What century are Mozilla living in? Most, even simple forms, don't use <form> elements and submit buttons anymore, they're all aJax. Therefore this workaround will be commonly bypassed.
People can debate if this is a good or bad thing, but ultimately the problem remains: This change will cause unexpected behavior when maxlength-ed stuff no longer obeys on thousands of popular websites.
Even if sites check it server-side, that doesn't mean the user experience isn't substantially degraded relative to obeying HTML standards.
Their justification for this change is nonsensical too:
> This change mainly aims at preventing an unexpectedly truncated password from being saved.
So why not limit it to input type=password? Heck why include textareas in this change, who is using a textarea for a password box?!
A lot of people still put them in forms. They just intercept the form submit to do with as the please. No putting them in a form also breaks accessibility
And a lot of sites don't. "This breaks a ton of things but not everything" isn't a good attitude to browser compatibility, particularly from a browser that already has a small market share.
> No putting them in a form also breaks accessibility
Nope. Screen readers have no concept of <form> fields, nor any concept of how the piping works below the surface when a <button> is pressed. I run a screen reader every single day.
One breaks the expectations of users, the other breaks the expectations of developers. On a website full of developers you'll probably see a lot more from one side than from the other.
I'm pretty sure being able to input text longer than the maximum allowable text into a field breaks user's expectations too. Users don't "win" because you made how a site works more confusing.
Their justification for this change is the only user-win (password truncation), and they could have trivially restricted this to passwords then body is hurt.
Users don't expect the length limit! that info isnt presented to them until the text is over-long and the clue is: Surprise! Truncate w/o warning. On more than just password fields.
Even if you use AJAX forms for logging in or registering (I'd prefer you didn't but whatever), you should still use the proper form validation API for things like this. If you use the proper HTML API for gathering data properly, you're most likely not affected badly functionality wise; only your UI will be affected because the form will refuse to be posted without proper explanation.
If the change really does get bypassed by everyone, that only underlines the sad state of modern website design relying completely on javascript.
I'm not sure why they don't limit this to just passwords but I can imagine it's easier to change the behaviour for all form elements than it is to change the behaviour of just password fields.
>Even if you use AJAX forms for logging in or registering (I'd prefer you didn't but whatever), you should still use the proper form validation API for things like this.
You don't even need to use "the proper form validation API". It's as simple as changing your ajax call from an onclick (on the submit button) to an onsubmit (on the form).
Agreed. Though, as a developer, I like to extend the submission actions a little bit to make error messages fit in with the rest of the site and maybe suggest what to do in order to correct the input (e.g. remove letters from phone numbers, pick a better password, etc.)
I do consider using the HTML5 form validation to be the proper validation API. Browser can do a lot without javascript and relying on their default behaviour is still making use of the validation API.
You're totally right, but the Firefox popover indicating what's going wrong doesn't go with some of the designs I make. On a bootstrap-based design I much prefer bootstrap-style error messages which are easy to do with Javascript, and the same is true for Material-based designs.
I do think that people generally overlook the built-in form validation though, and I like to use them as a fallback for Javascriptless environments to ensure everyone can get proper validation.
It's important to use form elements for accessibility even if your submitting another way. Also at least for me its a lot better to use the built in form validation then creating your own.
Your link doesn't support your statement, or even attempt to. Screen readers have no concept of <form> elements, nor do they differentiate on what happens behind the curtain when a button is pressed (e.g. aJax Vs. submit).
If you have an article that does explain your argument, please link it.
> Also at least for me its a lot better to use the built in form validation then creating your own.
How? The form can't be submitted until it's fixed.
>The form cannot be submitted until the user fixes the error [...]. The user will typically see a red border around the text field along with a validation message [...]
So Mozilla's non-standard compliant change broke one fewer site, problem solved?
Even for this site, why is Mozilla not limiting this breaking change designed to fix password fields to: Password fields. They haven't described why type=text or even textarea should be non-standard, only why type=password should be.
If they limited this to password fields, I'd have no issue. But per the code change they did not.
I’ve had issues pasting phone numbers into text fields, where the last digits get cut off because the form doesn’t want hyphens. I’d rather it paste in the full thing and then let me manually remove the hyphens/spaces.
