[cryptography] Oddity in common bcrypt implementation

Marsh Ray marsh at extendedsubset.com
Mon Jun 20 13:11:38 EDT 2011

On 06/20/2011 09:59 AM, Solar Designer wrote:
> On Wed, Jun 15, 2011 at 04:22:55AM +0400, Solar Designer wrote:
> Yesterday, I was informed of a bug in
> JtR, which also made its way into crypt_blowfish, and which made the
> hashes incompatible with OpenBSD's for passwords with non-ASCII characters
> (those with the 8th bit set).  Yes, it was an unintended/inadvertent
> sign extension.  What's worse, in some cases it results in other
> characters in those passwords being ignored.

This would result in false positives from JtR?

> Very nasty, and embarrassing.

Looks to me like a very ordinary bug.

JtR wasn't intended to be a security-critical piece of software. It 
doesn't need to be and it wasn't tested as such.

Taking code which works well for one set of requirements and re-using it 
in another context with a subtly different set of requirements is a 
classic Software Engineering mistake. AIUI, others borrowed JtR code and 
used it in a security-critical context. They didn't "recertify" it for 
its new usage, i.e. test it for false positives. This is a mistake on 
their part.

It's like taking a cell phone chip designed for terrestrial use and 
using it in a satellite. Sometimes you can save a lot of time and money 
by doing that kind of thing, but the burden is on you to ensure that it 
meets your special requirements.

> I am surprised this could go unnoticed for 13 years.

Perhaps it says something about the frequency of chars > 127 in actual 
user passwords? I don't even know how to type them on my US keyboard and 
I'd be reluctant to use them in my passwords.

Or maybe it also says something about the willingness of JtR users to 
report issues with false positives?

> I am trying to learn some lessons from this.

The best C developers might get the sign extension thing right 98% of 
the time. This bug is simply going to appear with some degree of 
frequency in everybody's code. The signedness of chars is even different 
between compiler platforms. It takes a ton of testing and independent 
review to weed out the other cases.

> More detail here:
> http://www.openwall.com/lists/oss-security/2011/06/20/2
> http://www.openwall.com/lists/oss-security/2011/06/20/6
> Although the code fix is a one-liner, fixing this in all affected
> software is difficult, especially where backwards compatibility matters.
> I'd appreciate any suggestions.

For places where it's used for password validation, it may need to be 
bug-compatible, right?

I was once in the middle of a disclosure about an authentication bug 
that also dealt with the thorny issue of backwards-compatibility.

Read http://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model
Expect to hear Denial, Anger, Bargaining, Depression, and Acceptance 
even from those you would least expect it.

Fix JtR of course, including the addition of an option to exploit the 
bug. :-)

I'd suggest fixing it with a run-time parameter to make it 
bug-compatible. The downstream vendors can then determine if and how it 
can be configured by the admin and decide on policies for the default 

What would be helpful for the downstream vendors is any expert guidance 
you could give on the severity to inform the policy decisions. E.g., 
"bug-compatible mode reduces cracking time by X% in cases where...".

- Marsh

More information about the cryptography mailing list