Bug 2611

Created attachment 2870 [details]
patch to add support

NOTE: refers to jbcrypt 0.4.0, but product is not selectable.

We have run into a problem with the prefix of bcrypt-hashed passwords. Our generated hash values include the prefix $2b$, but our crypt library rejects these, only accepting hash formats with the prefix $2a$.
Our current bcrypt java library (http://www.mindrot.org/projects/jBCrypt also https://github.com/jeremyh/jBCrypt) uses the modular crypt format (http://pythonhosted.org/passlib/modular_crypt_format.html) to store both the salt and the hash of the password.
The python library we have selected uses bcrypt.c. In (http://www.openwall.com/lists/oss-security/2012/01/02/4), 'Alexander' describes that Christos Zoulas discovered a wrap-around error. This is also described in https://en.wikipedia.org/wiki/Crypt_(C). Either way, the actual behavior in the c libarary is not truncation, but wrapping in a way that can eliminate significant (all) entropy in the overflow case (overflow is of the len variable which is uint8).
As a mitigation, some implementations use the $2b$ prefix which clarifies the behavior regarding long passwords (e.g. the actual behavior is now truncation). Implementations generally have addressed both the overflow and used the version bump to identify this change.
The jbcrypt library uses "minor >= 'a'" comparisons in many positions, but the critical section seems to be a check:
	if (salt.charAt(0) != '$' || salt.charAt(1) != '2') {
	    throw new IllegalArgumentException("Invalid salt version");
	}
	if (salt.charAt(2) == '$') {
	    off = 3;
	} else {
	    minor = salt.charAt(2);
	    if (minor != 'a' || salt.charAt(3) != '$') {
	        throw new IllegalArgumentException("Invalid salt revision");
	    }
	    off = 4;
	}
This code only supports prefixes $2a$ and $2$. It appears that the java implementation does not have the wrapping problem from the C implementation, but for compatibility, we would prefer that the java implementation include support for both.