What to use for password hashing? Any reason not to use jBCrypt?

Question

I'm planning to use jBCrypt for password hashing in a new web application, as it is supposed to be the best from what I've read. As I haven't used it before I'm looking into if there is any reason not to use it.

I have this:

• I haven't found it in the Maven repository (searched for jbcrypt and bcrypt at mvnrepository.org) which is a downer as I'd like to have my dependencies managed using a Maven repository if possible. If jBCrypt is the best of breed solution for password hashing I'd have to setup my own local repository and have it available that way. Or have I just missed it? Maybe it's in there somewhere?
• It's only at version 0.2, but maybe it's stable anyway and the reason for a low version number has some other cause?

Answer 1

I doubt stability is going to be an issue, since bcrypt itself is mature and its tiny, standardized wrappers don't do anything extraordinary. I'm happy with Damien Miller's other bcrypt wrapper, python-bcrypt, which is only on version 0.1.

I'm unfamiliar with Maven, but (heresy alert!) I doubt you need version control for a component as simple as bcrypt. To quote the site, the changes from v0.1 to v0.2 were "correctness, typo and API tweaks (fully backwards compatible)," and the TODO list is empty.

Answer 2

jBcrypt is probably fine as a crypto algorithm for your passwords; blowfish is relatively strong. Although there have been some reported implementation flaws in Blowfish itself, I don't find anything much reported about jBcrypt. On the other hand, Blowfish hasn't been tested nearly as heavily as other algorithms have, and a crack-style known-plaintxt attack often works better than expected, surprising crypto geeks.

So here's what I'd suggest:

• go ahead and use jBcrypt but protect your encrypted password files to the extent you reasonably can -- as you would using /etc/shadow on a UNIX system.
• Contrary to Nikhil's suggestion, I would pull the sources into your version control, for two reasons: (1) where else would you keep them, since you need them whenever you build, and (2) because there's always the chance the person doing jBcrypt will move on to other things, and you don't want to find yourself left dangling just before a delivery (which is inevitably when you'd find out.) In this kind of situation, I'd put the sources into your version control as if they were your on code, and then any changes can be inserted as if you'd built a new version yourself. No need to be more complicated than you normally would be.

Answer 3

As far as your concern that it's not mature, I was going to suggest that you set up your own JUnit tests comparing the results of jBcrypt and the more proven Bcrypt, to see if you get the same results, and then contribute those to the jBcrypt project.

But that's already been done:

... ships with a set of JUnit unit tests to verify correct operation of the library and compatibility with the canonical C implementation of the bcrypt algorithm.

Perusing the JUnit tests to see if they meet your level of satisfaction is where I'd start...