Yes, and PBKDF2 relies on other algorithms that have also shown problems. It's just looping and clever bitmasking (and takes about 10LOC to implement, assuming

Yes, and PBKDF2 relies on other algorithms that have also shown problems. It's just looping and clever bitmasking (and takes about 10LOC to implement, assuming you have hash_hmac easily available). So if there's a problem found with sha256 or whatever hashing function you choose it use it with, then it too has a problem. That's not to knock PBKDF2 - I'm just pointing out that both have flaws, and that people should use the right tool for the job. The "KDF" in "PBKDF2" stands for Key Derivation Function; i.e., it's for deriving a(n encryption) key. bcrypt exists basically for the sole purpose of password storage. In practical terms, it's more obvious how to use bcrypt's work factor as computers speed up than PBKDF2's iteration count, although either is quite suitable for the job. It's also easier to rehash bcrypt-stored passwords when upping your work factor - the old version will still verify, just check for $WF$ not matching your current work factor. PBKDF2 requires a bit more logic since you have to rehash with a different iteration count and do a second comparison, which conceivably also opens you up to a timing attack unless you're very careful about how you do it. To me, it's a matter of what a tool was designed for. Given that I have the right tool for the job, why use something that's designed for something else even though it works quite well?