djmdjm / jBCrypt

bcrypt for Java

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Invalid salt revision

domdorn opened this issue · comments

jBCrypt is not compatible with bCrypt hashes generated by other implementations, e.g. PHP or https://bcrypt-generator.com/

Caused by: java.lang.IllegalArgumentException: Invalid salt revision
at org.mindrot.jbcrypt.BCrypt.hashpw(BCrypt.java:665)
at org.mindrot.jbcrypt.BCrypt.checkpw(BCrypt.java:764)

e.g. "test" might be hashed as "$2y$10$h5jWvguJlBPJ8/1KkOBRGeApm9dj0430qnHK5iRp4lb2dBL4DhfnK"

jBcrypt expects a hash to start with $2a ..

General question: are you still supporting this library? The repository looks very outdated (last commits years ago..).

BTW there is https://github.com/kruton/jbcrypt which seems to be more recently touched.

@domdorn
I'm using https://github.com/Password4j/password4j and it passes the test

BCryptFunction bcrypt = BCryptFunction.getInstance(BCrypt.Y, 10);
Password.hash("test").with(bcrypt);

// $2y$10$kC7i7gde5oCLqMpC.vIEs.knpXCb6SpTWL4vWQlCfED/PJg/iSUGq

It seems constantly updated.

commented

Hashed passwords are stored with a prefix to identify the algorithm used. BCrypt got the prefix $2$.
...
A bug was discovered in crypt_blowfish🕗, a PHP implementation of BCrypt. It was mis-handling characters with the 8th bit set.

They suggested that system administrators update their existing password database, replacing $2a$ with $2x$, to indicate that those hashes are bad (and need to use the old broken algorithm). They also suggested the idea of having crypt_blowfish emit $2y$ for hashes generated by the fixed algorithm. Nobody else, including canonical OpenBSD, adopted the idea of 2x/2y. This version marker was was limited to crypt_blowfish🕗.

...
The versions $2x$ and $2y$ are not "better" or "stronger" than $2a$. They are remnants of one particular buggy implementation of BCrypt.

quote from https://stackoverflow.com/a/36225192

As I read this StackOverflow post, you should be able to change the prefix (ie, algorithm) to $2a$ and all should be well. But I did not test it, so YMMV.