I'd like to recommend to my fellow developers that we all use bcrypt to hash stored passwords. We all use java and I hesitate to recommend jBCrypt only because its latest version number (0.3) indicates that it is a beta release. I see that recent versions of Spring Security have included an implementation that is mostly the exact code from jBCrypt. By "mostly" I mean that Spring Security has changed it to meet their coding conventions and little else that I can detect. To me, Spring Security is a pretty good stamp of approval. My question is: would you all feel comfortable recommending Spring's implementation? If I test it and compare the results to actual bcrypt results, would this be good enough? How would I know if my tests were thorough?
2 Answers
You could audit the jBCrypt code yourself. It is small: one 750-line source code file, half of which being an array of constants. Moreover, since this is Java, you do not have to fear the dreaded "undefined behaviour" of C: if it works well on your machine, it will work well everywhere (for that kind of code, which does not involve threads, system access of floating point computations, the "write once, run everywhere" mantra of Java tends to be true).
You can also have a look at the accompanying TestBCrypt.java file: this looks like a reasonably thorough application of known test vectors (including some non-ASCII passwords). The code looks fine to me.
For most opensource projects, version numbers are meaningless, since they translate more the author's feeling of inner fulfillment than any actual technical quality of the software.
Note: of course, since the point of slow hashing is a budget race between the defender and the attacker, by using Java you are giving a 3x advantage to the attacker: he will use optimized C or assembly (or some FPGA). Yet, properly applied bcrypt, even with Java, should be enough to ensure that password storage is no longer the worst of your problems.
-
In the scenario where the attacker has captured the stored and hashed password, what difference could it possibly make what language was used to bcrypt the passwords in the first place?– mcgyver5Commented Oct 29, 2012 at 13:43
-
1@mcgyver5: bcrypt has a configurable iteration count. The higher the count, the harder the attack is for the attacker. But a higher count also implies more CPU effort when verifying a password. If you are using a suboptimal language, then you will not be able to rise that count as high as you would with a faster implementation; but the attacker will use C or assembly. It is a CPU race between attacker and defender; using Java instead of C is like wearing lead shoes to run a marathon. Commented Oct 29, 2012 at 13:57
-
I understand what you are saying, but the login scheme just has to do one trip through the algo to verify the login. The attacker has to try millions and that is why the multiple iterations will inconvenience him more than it will my servlet. Beyond that, no web framework or web application is going to employ the specialized hashing that the attacker will presumably use. In other words, it isn't correct to single out Java as having Lead shoes.– mcgyver5Commented Oct 29, 2012 at 17:18
BCrypt is definitely safe to recommend, whether it's Spring's version or the original Mindriot jBCrypt port. Don't let the version number scare you as it is just a result of the author's versioning scheme.
See http://www.mindrot.org/projects/jBCrypt/ for the release notes
