5 ms·
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 breakag
by rubyn00bie 6y ago
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)
- deleted 6y ago[deleted]
- franga2000 6y agoNot 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.
- eMSF 6y ago>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.
- franga2000 6y agoThe 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. [0] https://stackoverflow.com/a/32909765 https://stackoverflow.com/a/32909765
- eMSF 6y ago>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.
- franga2000 6y agoYou're right, it looks like I somehow read the number on the bottom axis wrong three times in a row (though it was 20 000). Thanks for the info on what crypt() actually does. I definitely need to look into that some more...
- gridlockd 6y agoWhat about 500kB? 5mB? At what point does it become reasonable to spend a few extra minutes on sanitizing user input?