3 ms·

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 a

by franga2000 6y ago

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.

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 ago
  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. [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 ago
      You'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...

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 ago
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. [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 ago
    You'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...