Regression with Bcrypt max password length

[strehle]

Describe the bug
There was a fix in bcrypt, e.g.
46f0dc6

To Reproduce
Create secret > 72.
Upgrade to newer spring security and validate the secret / credential

Expected behavior
Expect that existing scenarios work, but new created secrets can be rejected

Current behavior
Now we see http 500.

There are good descriptions about the issue and very often about solutions, like
https://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length/184090#184090

You can use the salt in Bcrypt to generate a HMAC_256 from input > 72 and then use same salt for bcrypt call.

But now we have a regression and the problem, that because of the CVE we should upgrade but if we upgrade we break integrations.

Sample

Callstack from UAA
java.lang.IllegalArgumentException: password cannot be more than 72 bytes
at org.springframework.security.crypto.bcrypt.BCrypt.hashpw(BCrypt.java:615) ~[spring-security-crypto-5.7.16.jar:5.7.16]
at org.springframework.security.crypto.bcrypt.BCrypt.hashpwforcheck(BCrypt.java:579) ~[spring-security-crypto-5.7.16.jar:5.7.16]
at org.springframework.security.crypto.bcrypt.BCrypt.checkpw(BCrypt.java:767) ~[spring-security-crypto-5.7.16.jar:5.7.16]
at org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder.matches(BCryptPasswordEncoder.java:133) ~[spring-security-crypto-5.7.16.jar:5.7.16]
at org.cloudfoundry.identity.uaa.util.CachingPasswordEncoder.internalMatches(CachingPasswordEncoder.java:86) ~[cloudfoundry-identity-server-xxxx.jar:?]

[ymind]

+1

[dbouclier]

We also experienced this regression in our systems after upgrading to spring boot 3.4.4.
We are using BCryptPasswordEncoder to create api key, unfortunately we were using a randomly generate string of 64 characters (with UTF8 it's 88 bytes 😩 )

That force us to regenerate all the api key 😭, I was not expecting that in a minor version upgrade.

I'm looking for advice or workaround to help migrating ?

[robinjhector]

The fact that this was made in a patch version, and not even mentioned in the release notes is beyond me

[dbouclier]

For folks like me who want to migrate without changing third parties secret/password
We ended with a work around using DelegatingPasswordEncoder

Migration steps:

• add to all existing hash a {bcrypt} prefix
• after a successful authentication flow using DelegatingPasswordEncoder, if the hash prefix is {bcrypt}, then update the hash with another encoder without any length limitation (for example: Argon2PasswordEncoder), update the hash with {argon2} prefix
• after some time, all the hashes are updated, so you can upgrade spring security 🎉

[jgrandja]

@strehle As you have already seen, the fix was applied to address CVE-2025-22228. Let me look into the StackExchange article you sent and see if I can come up with a solution without requiring you to upgrade the encoding.

Does the workaround mentioned by @dbouclier work for you?

[jgrandja]

@robinjhector

The fact that this was made in a patch version, and not even mentioned in the release notes is beyond me

See https://spring.io/blog/2025/03/19/spring-security-6-3-8-6-4-4-are-now-available

[strehle]

@strehle As you have already seen, the fix was applied to address CVE-2025-22228. Let me look into the StackExchange article you sent and see if I can come up with a solution without requiring you to upgrade the encoding.

I know the CVE and I am wondering why it is a CVE with this rate. I mean the issue was known before, but we "lived with it".
Now an update can break existing setups.

Does the workaround mentioned by @dbouclier work for you?

The workaround means replace brcrypt with argon2. Yea we have to do it, but it is nothing we want to have in a minor version bump of a dependent library

[gbrehmer]

of course better security is always good. But in this case the workaround means you can not update e.g. until all users have logged in again. this can take >12 month. At the end no real solution. Of course you could clone the old bcrypt classes and make your own custom bcrypt encoder with the old behavior during migration and with updated spring security libs already.

Much easier would be a backwards compatibility mode in the existing class. Then its not required to clone such classes

[strehle]

See https://spring.io/blog/2025/03/19/spring-security-6-3-8-6-4-4-are-now-available

This fix in open source is somehow ok, but if you pay for the spring enterprise license, what we do, then I cannot understand this fix for example in versions where you do not fix anything else. Here I recommend to revert it and to describe the issue. As mentioned if you run old versions in enterprise world you often have to live with limitations. The limit of 72 for secrets is OK (for now)