BCrypt has a fairly well documented maximum length of 72 bytes for passwords inputs. Anything longer than that is ignored.

This recently got some attention due to CVE-2025-22228 in Spring Security (GHSA). Interestingly, its fix just rejects all inputs that are longer than 72 bytes (UTF-8, so good luck explaining this requirement to users) both for hash creation (#hashpw) and hash validation (#checkpw).

The library Jenkins is currently using for password hashes stored in Jenkins' own user database and the Spring implementation share common ancestry, and the same behavior of silently ignoring input beyond 72 bytes is present in current releases of Jenkins.

The Jenkins security team does not consider this behavior to be a vulnerability, as brute-forcing 72 byte prefixes of passwords is infeasible unless someone encodes more than just an actual password in the bcrypt hash and reduces the effective length of the password, like the well-publicized case of Okta last year.

This is also reflected in the upstream fix not adding support of more than 72 bytes, but rejecting anything longer than that.

We should still improve the implementation of password hashes in Jenkins' own user database.

Some ideas:

• Switch the format to (SHA) hash, then bcrypt (with backward compatibility support for existing password). This will allow all password characters to be relevant due to the SHA hash's fixed length. Ideally this would remain backwards compatible. TBD how well that will work with CasC defining user passwords, perhaps if we don't consider the current format deprecated for passwords <72 bytes it's fine to just continue?
• An an alternative to the above, Wadeck points to Argon2id as an alternative if we switch the storage format anyway, with Argon2PasswordEncoder there is an implementation in Spring Security.
• Prohibit creation of new passwords >72 bytes, but continue supporting use of existing ones, ideally with a notice shown to users that they should set a new password, as part of it is ignored. Could be coupled with the first item to tell them to just set the current password again to make all of it relevant.
• Prohibit passwords >72 bytes entirely, given how rare this probably is, and how (relatively) easy it would be to work around.

At the same time we could look into removing the library we use for BCrypt and use the implementation from Spring, given the history around it.