* There's no serious set of test cases. Many Bcrypt implementations were bitten recently when it turned out that they didn't properly handle characters with the high bit set.
* It only ever uses a work factor exponent of 8 which is probably too small for most modern use.
* Even if the password hash specifies a different work factor it will still use 8, and then fail.
* It's not going to interoperate with other implementations for these two reasons.
* The timing of regex's excecution probably leaks information about the salt.
* It uses perl's 'eq' for comparing the strings. The time that this function takes to run is probably dependent on the length of the matching prefix of the two strings. So there's possibly a timing attack enabling an unauthenticated remote attacker to read some of the password hash string. He may need to know the salt, but the salt is not considered a strongly-kept secret. Nate Lawson's blog is a great source on this topic http://rdist.root.org/2010/01/
Comments
Yeah, at least by using md5 one can easily screw everything up in an obvious way.
I think you were being sarcastic, but sometimes that is indeed an improvement.
I think that point of the sarcasm was that using MD5 is the obvious screw-up.
Yes, I understand that. I was saying that an obviously screwed-up system is often better than a subtly screwed-up one.
Nevertheless, a well-implemented MD5-based system could still be "less bad" than the buggy home-rolled bcrypt in that link.
How is the latest iteration on the blog?
What's the link to the exact code in question? I don't see it.
https://gist.github.com/1071698
Some quick impressions:
* There's no serious set of test cases. Many Bcrypt implementations were bitten recently when it turned out that they didn't properly handle characters with the high bit set.
* It only ever uses a work factor exponent of 8 which is probably too small for most modern use.
* Even if the password hash specifies a different work factor it will still use 8, and then fail.
* It's not going to interoperate with other implementations for these two reasons.
* The timing of regex's excecution probably leaks information about the salt.
* It uses perl's 'eq' for comparing the strings. The time that this function takes to run is probably dependent on the length of the matching prefix of the two strings. So there's possibly a timing attack enabling an unauthenticated remote attacker to read some of the password hash string. He may need to know the salt, but the salt is not considered a strongly-kept secret. Nate Lawson's blog is a great source on this topic http://rdist.root.org/2010/01/