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?

Illegitimacy

Answer 1

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.

Kipkipling

Yes it's in my version control now. I should Google for these known weaknesses in Blowfish, as it's news to me. Regarding "crack style known-plaintext attack", do you mean a brute force dictionary type attack? If that's the cast it's the whole reason I want to use Blowfish, as it's a slow algorithm. – Illegitimacy

No, look up Alec Muffet's crack: it precomputes a big dictionary of common passwords and then compares the ciphertexts. And it's not that Blowfish has known flaws, it's that some implementaitons have been reported to have flaws. – Kipkipling

Hm, all right. But I'm using pasword salting so a dictionary attack shouldn't be possible in that manner. – Illegitimacy

So does passwd(1). Alec beats it anyway. But known-plaintext and dictionary attacks are distinct things. en.wikipedia.org/wiki/Known-plaintext_attack en.wikipedia.org/wiki/Dictionary_attack – Kipkipling

Answer 2

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...

Halftone

Yes I have. The JUnit tests are still quite limited and based on hard coded values in the test methods. So if I don't compare those to values from BCrypt I still can't be sure that the values actually are from BCrypt (which I'm sure they are). – Illegitimacy

Answer 3

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.

Intuitivism

jBcrypt is actually not a wrapper. It's a native implementation. I'm using it now, I incorporated the source code into the project. – Illegitimacy