While criticism is good, the condescending way it is presented, as well as being overly critical are bad. Example:
"Total undue reverence for NIST and FIPS standards; for instance, the book recommends PBKDF2 over bcrypt and scrypt (amusingly: the book actually recommends against scrypt, which is too new for it) because it's standardized."
I know people love scrypt and bcrypt, and have been proven safe so far, but there are advantages to use standardized methods. An implementation can make something less safe than the standard.
This is silly. There is no advantage to using PBKDF2 other than to placate PHBs. PBKDF2 (as commonly implemented, with HMAC-SHA2) is faster than bcrypt and scrypt and particularly straightforward to implement in GPU crackers.
bcrypt is also approximately the same age as PBKDF2.
And, finally, standardization is a very poor substitute for security analysis. PKCS1v1.5 is also a standard. If you want to argue against bcrypt, you'll have to marshal actual arguments.
I'm arguing that there may be advantages in using standardized methods (for interoperability) and especially implementations.
Which one is safer, using PBKDF2 from a known implementation or the "bcrypt library" for Ruby/Node that someone just posted to github? Oh what do you mean that's not how you read secure random numbers?
> Which one is safer, using PBKDF2 from a known implementation or the "bcrypt library"
What kind of dilemma choice is that? It should rather be:
"Which one is safer, using PBKDF2 from a known implementation or bcrypt from a known implementation?"
But even that question is erroneous. After all, why shouldn't we just use PBKDF2 from RSA's known BSAFE implementation? What could possibly go wrong with that?
Or if you don't like RSA because of da Feds, why not use the known-good OpenSSL for securing data in motion instead of something new and untested like stunnel or spiped?
Known implementations are a very good consideration factor. You should use TLS (though maybe not OpenSSL's) in general instead of designing your own secure transport. But being from a known implementation should not be the only factor you consider otherwise you're just cargo culting. You have to understand pros/cons of each solution, even if that means you have to learn a little bit about the problem space.
Yes, "Bob's bcrypt lib" is safer (apart from some serious mistake or compromise, which are not rare) than hashing your passwords with a rock-solid sha1 library.
"But being from a known implementation should not be the only factor you consider otherwise you're just cargo culting"
Of course
In the same way some people blindly answer "use bcrypt" to any mention of password hashing.
While criticism is good, the condescending way it is presented, as well as being overly critical are bad. Example:
"Total undue reverence for NIST and FIPS standards; for instance, the book recommends PBKDF2 over bcrypt and scrypt (amusingly: the book actually recommends against scrypt, which is too new for it) because it's standardized."
I know people love scrypt and bcrypt, and have been proven safe so far, but there are advantages to use standardized methods. An implementation can make something less safe than the standard.