On: How Dropbox securely stores your passwords

[evunveot]

> Some implementations of bcrypt truncate the input to 72 bytes, which reduces the entropy of the passwords.... By applying [SHA512], we can quickly convert really long passwords into a fixed length 512 bit value, solving [that problem].

This part confused me. How can truncating to 72 bytes be a more severe reduction in entropy than generating a 64-byte hash?

[grenoire → evunveot]

Password lengths are variable. With passwords longer than 72 ASCII characters, you will lose entropy after that.

Let A be a 72 character long string, and B be A + X. Regardless of what X is, when bcrypted the result for A and B will be the same.

[crpatino → grenoire]

A random X does not reduce the entropy of bcrypt(B), just fails to add any additional entropy beyond bcrypt(A)'s.

Assuming C, where len(C) < 72, I don't know if it is possible at all to chose some value of Y such that:

D:= C+Y

Entropy(bcrypt(D))< Entropy(bcrypt(C))

[Dylan16807 → crpatino]

"Lose" meaning it is thrown away. Not "lose" meaning it subtracts.

[CiPHPerCoder → evunveot]

If you had two users with a very long password, but the first 100 characters were identical, they'd collide.

  - Pre-hashing makes this less likely.
  - Encoding the pre-hashed value to prevent NUL bytes is important.

But it's a bandaid solution, to be quite honest. We're better served by migrating to Argon2i, which doesn't have these quirks.

[microcolonel → evunveot]

I think they're talking about entropy per bit. If they hash to 64 bytes, they integrate all of the entropy of the password, if they truncate to 72 bytes, they throw away all entropy past 72 bytes. This could be a huge problem if you're one of those people who uses a common prefix with a suffix as their password pattern for passwords they need to remember.

[Dylan16807 → microcolonel]

Especially if your password has a lot of words, you have a very low entropy per byte. It's not the worst thing in the world at 72 bytes, but if you were choosing between a 16 byte hash of a sentence and an 18 byte truncation, the hash is going to have vastly more entropy.

And 512 bits is more than plenty.

[spronkey → Dylan16807]

> And 512 bits is more than plenty.

Famous last words.

[Dylan16807 → spronkey]

"A typical supernova releases something like 1051 ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states."

You're not getting through 512 bits of entropy unless your cryptographic methods are severely broken, so broken that having more bits would not meaningfully help.