[cryptography] Oddity in common bcrypt implementation
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
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:
> 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
I was once in the middle of a disclosure about an authentication bug
that also dealt with the thorny issue of backwards-compatibility.
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
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...".
More information about the cryptography