4 ms·

PBKDF2 is actually a crappy standard: - The work factor depends on the length of hash. For example, if you compute and store 64 bytes of PBKDF2-HMAC-SHA256, an

by dchest 11y ago

PBKDF2 is actually a crappy standard: - The work factor depends on the length of hash. For example, if you compute and store 64 bytes of PBKDF2-HMAC-SHA256, an attacker needs to only compute the first 32 bytes to verify the guess, and with PBKDF2 it means doing half the work. - In most common use (with HMAC), it inherits HMAC "vulnerability": a password longer than the hash function block is equal to the its hash (see this Twitter thread: https://twitter.com/dchest/status/421595430539894784 https://twitter.com/dchest/status/421595430539894784). For example, `plnlrtfpijpuhqylxbgqiiyipieyxvfsavzgxbbcfusqkozwpngsyejqlmjsytrmd` and `eBkXQTfuBqp'cTcar&g*` have the same PBKDF2-HMAC-SHA1 hash. (Scrypt is also vulnerable, BTW, as it uses PBKDF2-HMAC-SHA256.) - PBKDF2 is commonly used with hashes which are fast on GPU or custom hardware and require tiny memory, thus making defense/attack cost ratio very bad. See scrypt paper for cost estimates (https://www.tarsnap.com/scrypt/scrypt.pdf https://www.tarsnap.com/scrypt/scrypt.pdf). BTW, we had Password Hashing Competition (https://password-hashing.net https://password-hashing.net), the (tweaked) winner of which will hopefully be widely used in the future.

CodesInChaos 11y ago
It's difficult to implement efficiently: * If you use the underlying hash as a black-box, each HMAC invocation compresses 4 blocks. An optimized implementation will only require 2. Many implementations (e.g. the .NET one) don't include that optimization and thus suffer from a 2x slowdown compared to the attacker's implementation. * If you use HMAC naively, it'll hash the whole password on each iteration, opening a DoS attack. Django made this mistake (see 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... ) It abuses the underlying hash: It xors together the outputs of different iteration numbers. This can interfere with the feed-forward of certain hash constructions. As far as I can tell this does not cause security issues, but it's still very dirty. --- Personally I'd go so far as to say that it's worse than PBKDF1 with a sufficiently wide underlying hash.
zeveb 11y ago
> - The work factor depends on the length of hash. For example, if you compute and store 64 bytes of PBKDF2-HMAC-SHA256, an attacker needs to only compute the first 32 bytes to verify the guess, and with PBKDF2 it means doing half the work. That's a fair criticism. In that respect, a better design might have been to generate a seed S using the PBKDF2 core, then just spit out HMAC(S, 1), HMAC(S, 2) for the derived key. I don't know if that would have had its own issues though; I'm not a cryptologist. > In most common use (with HMAC), it inherits HMAC "vulnerability": a password longer than the hash function block is equal to the its hash True, but as you imply it's really not a vulnerability. And it's certainly better than limiting passwords to 56 bytes, as bcrypt does (with human-memorable passwords, 56 bytes really aren't enough). > - PBKDF2 is commonly used with hashes which are fast on GPU or custom hardware and require tiny memory, thus making defense/attack cost ratio very bad. Sure, scrypt is better. But scrypt is not what 'everyone' uses: bcrypt is.

by dchest 11y ago

CodesInChaos 11y ago

It's difficult to implement efficiently: * If you use the underlying hash as a black-box, each HMAC invocation compresses 4 blocks. An optimized implementation will only require 2. Many implementations (e.g. the .NET one) don't include that optimization and thus suffer from a 2x slowdown compared to the attacker's implementation. * If you use HMAC naively, it'll hash the whole password on each iteration, opening a DoS attack. Django made this mistake (see 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... ) It abuses the underlying hash: It xors together the outputs of different iteration numbers. This can interfere with the feed-forward of certain hash constructions. As far as I can tell this does not cause security issues, but it's still very dirty. --- Personally I'd go so far as to say that it's worse than PBKDF1 with a sufficiently wide underlying hash.

zeveb 11y ago

> - The work factor depends on the length of hash. For example, if you compute and store 64 bytes of PBKDF2-HMAC-SHA256, an attacker needs to only compute the first 32 bytes to verify the guess, and with PBKDF2 it means doing half the work. That's a fair criticism. In that respect, a better design might have been to generate a seed S using the PBKDF2 core, then just spit out HMAC(S, 1), HMAC(S, 2) for the derived key. I don't know if that would have had its own issues though; I'm not a cryptologist. > In most common use (with HMAC), it inherits HMAC "vulnerability": a password longer than the hash function block is equal to the its hash True, but as you imply it's really not a vulnerability. And it's certainly better than limiting passwords to 56 bytes, as bcrypt does (with human-memorable passwords, 56 bytes really aren't enough). > - PBKDF2 is commonly used with hashes which are fast on GPU or custom hardware and require tiny memory, thus making defense/attack cost ratio very bad. Sure, scrypt is better. But scrypt is not what 'everyone' uses: bcrypt is.