3 ms·

Your math is incorrect. Sha256 can support arbitrarily long inputs. You can easily verify this claim by googling a Sha256 calculator and giving it 2 inputs : Fi

Your math is incorrect. Sha256 can support arbitrarily long inputs. You can easily verify this claim by googling a Sha256 calculator and giving it 2 inputs : First your 36-character "password" and next the same password with an extra character. You will notice that the outputs will be different.

teddyh 6y ago
With a password longer than about 36 characters, the pigeonhole principle comes into play, and there will exist a sub-36-length character password with the same hash as the longer password.
- baobabKoodaa 6y ago
  Right, but that doesn't refute the original point: you can support infinitely long passwords by hashing them. If we compare truncating a password to 36 characters vs hashing a password to a 36-character hash, hashing is much better. The hash is guaranteed to have at least as much entropy as the original password, up to 36 characters of entropy (yes, the hash can not have more than 36 characters of entropy, we get it, that's not the point, nobody is brute-forcing passwords that actually have 36 characters of entropy). I'll provide an edge case example to prove my point: suppose someone has a password that repeats the character 'q' 100 times, then repeats the character 'a' 100 times, and so on, until the password contains 8 randomly selected characters. This password has (slightly more than) 8 characters of entropy, right? If you truncate the password to 36 characters, the password will simply be 'q' repeated 36 times, so the truncated password will have (slightly more than) 1 character of entropy, right? But if you hash the 800-character input to a 36-character hash, the hash will contain exactly as much entropy as the input: (slightly more than) 8 characters worth. Maybe the example with 36 characters doesn't seem realistic to you, but my previous bank (Handelsbanken) actually secretly truncated passwords to 8 characters. I was not aware of this, and I had a password that contained multiple consecutive words (like correcthorsebatterystaple). I thought I had a secure password, little did I know my password was actually a single word because of the truncation. Now, if my bank had instead hashed user inputs to an 8-character hash, and used that as the password to their legacy system that only supports passwords up to 8 characters, my password would have actually contained 8 characters of entropy.
  - Sammi 6y ago
    Yes exactly. Hence the quotes around the infinitely. Your chances of starting out with more entropy in a 800 char passphrase is likely to be larger than what you are likely to have when starting with a 36 char passphrase. If you hash a 36 char passphrase then you retain most of the entropy of that 36 chars. No more no less. If you hash a 800 char passphrase then you maintain most of the entropy of that in the resulting 36 chars. Which is likely to be more.
  - teddyh 6y ago
    But that’s not what Sammi described as “support” upthread: “support "infinitely" long passwords without any significant loss of entropy.”¹. That description – i.e. “without loss of entropy” – is what I took issue with, due to the pigeonhole principle. 1. https://news.ycombinator.com/item?id=26866624 https://news.ycombinator.com/item?id=26866624
    - baobabKoodaa 6y ago
      Personally I don't think there's a practical difference between having 1000 bits of entropy in your password versus 256 bits of entropy, but fair enough.

teddyh 6y ago

With a password longer than about 36 characters, the pigeonhole principle comes into play, and there will exist a sub-36-length character password with the same hash as the longer password.

baobabKoodaa 6y ago
Right, but that doesn't refute the original point: you can support infinitely long passwords by hashing them. If we compare truncating a password to 36 characters vs hashing a password to a 36-character hash, hashing is much better. The hash is guaranteed to have at least as much entropy as the original password, up to 36 characters of entropy (yes, the hash can not have more than 36 characters of entropy, we get it, that's not the point, nobody is brute-forcing passwords that actually have 36 characters of entropy). I'll provide an edge case example to prove my point: suppose someone has a password that repeats the character 'q' 100 times, then repeats the character 'a' 100 times, and so on, until the password contains 8 randomly selected characters. This password has (slightly more than) 8 characters of entropy, right? If you truncate the password to 36 characters, the password will simply be 'q' repeated 36 times, so the truncated password will have (slightly more than) 1 character of entropy, right? But if you hash the 800-character input to a 36-character hash, the hash will contain exactly as much entropy as the input: (slightly more than) 8 characters worth. Maybe the example with 36 characters doesn't seem realistic to you, but my previous bank (Handelsbanken) actually secretly truncated passwords to 8 characters. I was not aware of this, and I had a password that contained multiple consecutive words (like correcthorsebatterystaple). I thought I had a secure password, little did I know my password was actually a single word because of the truncation. Now, if my bank had instead hashed user inputs to an 8-character hash, and used that as the password to their legacy system that only supports passwords up to 8 characters, my password would have actually contained 8 characters of entropy.
- Sammi 6y ago
  Yes exactly. Hence the quotes around the infinitely. Your chances of starting out with more entropy in a 800 char passphrase is likely to be larger than what you are likely to have when starting with a 36 char passphrase. If you hash a 36 char passphrase then you retain most of the entropy of that 36 chars. No more no less. If you hash a 800 char passphrase then you maintain most of the entropy of that in the resulting 36 chars. Which is likely to be more.
- teddyh 6y ago
  But that’s not what Sammi described as “support” upthread: “support "infinitely" long passwords without any significant loss of entropy.”¹. That description – i.e. “without loss of entropy” – is what I took issue with, due to the pigeonhole principle. 1. https://news.ycombinator.com/item?id=26866624 https://news.ycombinator.com/item?id=26866624
  - baobabKoodaa 6y ago
    Personally I don't think there's a practical difference between having 1000 bits of entropy in your password versus 256 bits of entropy, but fair enough.