3 ms·

> Some implementations of bcrypt truncate the input to 72 bytes, which reduces the entropy of the passwords. Other implementations don’t truncate the input and

by Freaky 10y ago

> Some implementations of bcrypt truncate the input to 72 bytes, which reduces the entropy of the passwords. Other implementations don’t truncate the input and are therefore vulnerable to DoS attacks because they allow the input of arbitrarily long passwords. Huh? BCrypt works by stuffing the password into a 72 byte Blowfish key and using it to recursively encrypt a 24 byte payload. Either it's truncating, or it's pre-hashing the password to fit much like they are. The link they use to justify it is funny: http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/ http://arstechnica.com/security/2013/09/long-passwords-are-g... That's just a naive PBKDF2 implementation that's pointlessly reinitializing the HMAC context each iteration instead of just doing it once at the start. The difference between storing a 1 byte and a 1MB password with PBKDF2 should be on the order of a couple of milliseconds.

arielb1 10y ago
Having the SHA-512 hash at the beginning simplifies the implementation because the "security" code only needs to handle 64-byte random strings (which are truncated to 54-byte strings for `bcrypt`, but still...). That removes all sorts of stupid edge cases that come with variable-length strings.
- Freaky 10y ago
  > Having the SHA-512 hash at the beginning simplifies the implementation The hash is there to ensure very long passwords contribute entropy to the final hash instead of being truncated. It also ensures the entropy is evenly distributed - every bit of the password affects every bit of the hash. > the "security" code only needs to handle 64-byte random strings You can't feed any typical BCrypt implementation a raw SHA-512 hash because it's not binary safe - it truncates at the first NULL byte. Well, you can, and it'll appear to work, but it'll be laughably easy to break. It's a pretty stupid sharp edge IMO. > which are truncated to 54-byte strings for `bcrypt` 72 bytes, because that's the size of the key array. 56 bytes is just where extra entropy helps less, because the last 16 bytes don't affect every bit of the output. > That removes all sorts of stupid edge cases that come with variable-length strings. It's just treated as a circular buffer. And what are we doing here, implementing our own version of BCrypt? Yeah, that certainly simplifies things :P

by Freaky 10y ago

arielb1 10y ago

Having the SHA-512 hash at the beginning simplifies the implementation because the "security" code only needs to handle 64-byte random strings (which are truncated to 54-byte strings for `bcrypt`, but still...). That removes all sorts of stupid edge cases that come with variable-length strings.

Freaky 10y ago
> Having the SHA-512 hash at the beginning simplifies the implementation The hash is there to ensure very long passwords contribute entropy to the final hash instead of being truncated. It also ensures the entropy is evenly distributed - every bit of the password affects every bit of the hash. > the "security" code only needs to handle 64-byte random strings You can't feed any typical BCrypt implementation a raw SHA-512 hash because it's not binary safe - it truncates at the first NULL byte. Well, you can, and it'll appear to work, but it'll be laughably easy to break. It's a pretty stupid sharp edge IMO. > which are truncated to 54-byte strings for `bcrypt` 72 bytes, because that's the size of the key array. 56 bytes is just where extra entropy helps less, because the last 16 bytes don't affect every bit of the output. > That removes all sorts of stupid edge cases that come with variable-length strings. It's just treated as a circular buffer. And what are we doing here, implementing our own version of BCrypt? Yeah, that certainly simplifies things :P