> - 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 f

> - 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.