Earlier quoted context omitted.
Web servers have max request size for this reason
So 1MB passwords are reasonable?
Yes
Text exceeding maxlength will no longer be truncated when pasted in Firefox 77
131–140 of 145 posts
Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77
#132Earlier quoted context omitted.
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…
>For one, a sha256 hash of 50kB would take a good quarter of a second (possibly more, I just ). You're probably thinking 50MB. Hashing 50kB should be almost instantaneous.
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.
Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77
#133Earlier quoted context omitted.
Why not?
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. Th…
[deleted]
Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77
#134Earlier quoted context omitted.
Why not?
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.
You would truncate to 72 bytes, not 20 characters (which might be more than 72 bytes anyway).
Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77
#135Earlier quoted context omitted.
Why not?
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.
How would the user tell the 73rd byte is truncated? Might as well call bcrypt itself misleading.
In any case this doesn’t preclude client-side validation.
Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77
#136> 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 elements and submit buttons anymore…
> Most, even simple forms, don't use elements and submit buttons anymore, they're all aJax.
> This change will cause unexpected behavior when maxlength-ed stuff no longer obeys on thousands of popular websites.
Does nobody or "thousands of popular websites" use ? Which one is it?
Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77
#137Earlier quoted context omitted.
You can also trivially truncate to 72 bytes server side.
That's a horrible thing to do. 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.
Ah the explanation this was missing was that the length validation for bcrypt is sufficient to bypass truncation.
Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77
#138Earlier quoted context omitted.
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.
You would truncate to 72 bytes, not 20 characters (which might be more than 72 bytes anyway).
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.
Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77
#139Earlier quoted context omitted.
>For one, a sha256 hash of 50kB would take a good quarter of a second (possibly more, I just ). You're probably thinking 50MB. Hashing 50kB should be almost instantaneous.
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 sim…
>extrapolating to 50kB gives me 0.3625 seconds
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.
Re: Text exceeding maxlength will no longer be truncated when pasted in Firefox 77
#140Earlier quoted context omitted.
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.
> 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…
A KDF is not a hash function, and I said "significantly" for a reason.
If adding a megabyte of input causes the original megabyte to get hashed or otherwise processed once, then you pass the test.
If adding a megabyte of input causes the original megabyte to get fed into your algorithm 100000 times, then you fail the test.