91–100 of 145 posts
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.
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?
Earlier quoted context omitted.
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 sp…
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 2…
You're probably thinking 50MB. Hashing 50kB should be almost instantaneous.
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 agen…
>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?
[1] https://html.spec.whatwg.org/multipage/input.html#attr-input...
Highlights from the bug report[1][2]: - 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 discussi…
We discussed the problem on #security and we moved to bugzilla once we kinda had a solution (it is hard to discuss solutions on bugzilla. :) Here is a link to the chat: https://matrix.to/#/!xSFwJMLGSLXLaSUrHr:mozilla.org/$o3a38gf...
Earlier quoted context omitted.
It's common in practice even if it shouldn't be. Also many bcrypt implementations truncate input longer than 72 characters.
You can also trivially truncate to 72 bytes server side.
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.
Earlier quoted context omitted.
It's common in practice even if it shouldn't be. Also many bcrypt implementations truncate input longer than 72 characters.
> 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 a…
> 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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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:…
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.