SEC-3121: Support for bcrypt revision $2b$

[spring-projects-issues]

Peter De Wachter (Migrated from SEC-3121) said:

In February 2014 a new revision of the bcrypt algorithm was published, which Spring Security does not yet implement. This is starting to cause interoperability problems, as various tools now generate bcrypt hashes that are not supported by Spring Security.

[spring-projects-issues]

Cory Berg said:

Interestingly, I found that the both the Spring bcrypt and the mindrot version seem to still have a bcrypt prefix of $2a$ which causes interoperability problems with, among other things, PHP (which uses $2y$, see http://php.net/manual/en/function.password-hash.php). That means one cannot validate passwords generated in something like PHP Laravel with Spring, without hand-changing the prefix in the Spring version. After I did this manual change, I was able to validate against $2y$ prefixed hashes from PHP. Perhaps someone who is more familiar with the theory of bcrypt could comment?

[jeanbza]

This is kind of interesting. What's the general approach for this? Support both through config + defaults, switch to supporting the new one, etc?

[pdewacht]

The reference URL got lost in the migration. This message explains the change:
https://marc.info/?l=openbsd-misc&m=139320023202696

[icey502]

You guys are welcome to my version of the bcrypt code, it is essentially the same except I replaced the hard-coded version string usage with something that I could modify to comply with the PHP stack I was up against at the time. Trivial workaround once I realized what was happening. I could imagine a "real" solution involving either a configuration setting or some kind of apriori inspection of the revision, possibly both. To give an idea (there are several areas that I had to touch to make it work, but the approach is the same):

private static final char SALT_REVISION_HACK_PHP = 'y';
...
in gensalt(...):
....
//rs.append("$2a$"); <-- original
rs.append("$2"+SALT_REVISION_HACK_PHP+"$"); <-- yucky but working change

Gross, but operational :-) Alas I am not a Bcrypt expert by any stretch, so alternate validation is probably a good idea.

[neuhaus]

The webpage for the openwall crypt_blowfish library which also implements bcrypt has some information and pointers regarding $2b$ and $2y$.

[rwinch]

The problem with just parsing these patterns is that they all behave slightly differently. This is the reason that the different prefixes exist in the first place. This means if we run into the edge case where there was a bug, then the password will not verify. So just changing the identifier may work in a large number of cases, but it won't for all.

I don't think we want to pretend that this will work with the bad implementations of BCrypt.

If we want to update the version of BCrypt, then we need mindrot to update their implementation so that we know whatever version we are parsing with is actually compatible with this implementation. Alternatively, we would consider using bouncy castle

[kopax]

Any update on this ?

I have the same issue using https://github.com/wclarie/openldap-bcrypt module for OpenLDAP.
The BCrypt password doesn't pass the test:

[rwinch]

@kopax No updates from my side.

We cannot just change the prefix for the reasons outlined in #3320 (comment) This means we need to find a credible crypto library that supports the additional prefixes.

You could investigate if bouncy castle supports the additional prefixes. If it does, then sending a PR that delegates to Bouncy Castle would get merged in. If not, then you need to try and get Bouncy Castle or Mindrot to update their implementations.

[bytor99999]

So our encrypting passwords and then checking for passwords are using the exact same code in Spring Security and for some users the first password is randomly generated, then sent to the encrypt code and saved to our users table. The user gets an email with the generated password for them to use to login. They go to our app and try to login and it fails because of this issue. We are not using any alternative encryptor or generator, it is all the same, so why would the creation of the encryption when we generate the password have these different patterns?

[bytor99999]

Any more updates on this? It is getting to be a real problem. More and more encryptors are using other variations and we are getting tons of calls from our users saying they can't login to our application and we spend 30 minutes trying to get a password to work for them, when we should be working on programming our application more. As I mentioned in my comment in November, Spring Security is even creating encrypted Strings with the different variations.

[nidi3]

As per https://security.stackexchange.com/questions/20541/insecure-versions-of-crypt-hashes I understand that 2a and 2y are identical and 2y exists only to mark the fix of an implementation problem in crypt_blowfish.
So at least 2y could be accepted by Spring Security to allow interoperability with PHP.