121–130 of 145 posts
I've definitely been bit by this and it definitely took hours to debug
I'm curious, could you describe the usecase?
This breaks my use case function shorten(text, length) const t = document.createElement('input') t.maxlength = length t.value = text return t.value }
Earlier quoted context omitted.
> 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…
A kilobyte limit is fine but > 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.
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.
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?
Hash the password on the client side before submitting to the server.
[1] https://stackoverflow.com/questions/33080103/ios-safari-igno... [2] https://stackoverflow.com/questions/27319642/is-there-a-work...
Earlier quoted context omitted.
> 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:…
> 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 an…
Earlier quoted context omitted.
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.
There's also an extension called Don't Fuck With Paste.
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 im…
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.