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