OpenBSD Journal

bcrypt password hash bugs fixed, version changes and consequences

Contributed by tbert on from the passwords all hashed up dept.

Ted Unangst (tedu@) wrote in to tell us about the practical consequences of a newly discovered bug in bcrypt(3), the function commonly used to generate password hashes:

[This email isn't just about OpenBSD; please forward it to the relevant places and people.]

Short version:

Mistakes were made. Magic numbers have changed. $2b$ is the hash of the future.

Background:

The original bcrypt code (released in OpenBSD 2.1) identified itself as $2$. Shortly after release, a bug was fixed and the hash identifier changed to $2a$. Support for "minor" versions wasn't really planned, but it was backwards compatible.

Solar Designer wrote a second implementation of bcrypt. This reimplementation suffered from a flaw dealing with 8 bit characters, and led to the introduction of the 'x' and 'y' flavors. OpenBSD did not have this problem and supports neither 'x' nor 'y' hash versions.

Current problem:

Solar found a bug in the OpenBSD implementation of bcrypt when hashing long passwords. The length is stored in an unsigned char type, which will overflow and wrap at 256. Although we consider the existence of affected hashes very rare, in order to differentiate hashes generated before and after the fix, we are introducing a new minor 'b'.

OpenBSD 5.5 (coming this spring) will accept and verify 'b' hashes, although it will still generate 'a' hashes. OpenBSD 5.6 (coming this fall) will change to generating 'b' hashes by default.

A future release of Solar's bcrypt code should also support 'b'.

What this means:

For OpenBSD users, all systems that might verify a password need to be upgraded before any systems start generating password hashes. This may be a concern in YP environments if ypcipher has been changed from the default and you attempt to run a mix of 5.4 and 5.6 systems.

For 3rd parties, adding future compatible support for $2b$ now will enable a smoother transition in the future. The decision to generate 'b' hashes should be based on one's need to support password verification on a heterogenous mix of systems.

Hopefully this will be the last version change for a while.

Thanks to Solar Designer for helping to keep us honest.

(Comments are closed)


Comments
  1. By Anonymous Coward (71.13.236.243) on

    ""OpenBSD 5.5 (coming this spring) will accept and verify 'b' hashes, although it will still generate 'a' hashes. OpenBSD 5.6 (coming this fall) will change to generating 'b' hashes by default.""

    Is there a way to force 'b' hash generation in OpenBSD 5.5? I don't have a need to communicate with legacy systems.

    Comments
    1. By sthen (2001:8b0:648e:cc01:f2de:f1ff:fef9:a752) on

      > ""OpenBSD 5.5 (coming this spring) will accept and verify 'b' hashes, although it will still generate 'a' hashes. OpenBSD 5.6 (coming this fall) will change to generating 'b' hashes by default.""
      >
      > Is there a way to force 'b' hash generation in OpenBSD 5.5? I don't have a need to communicate with legacy systems.

      There isn't. But unless you have very long passwords there is really no problem with the 'a' hashes so there is no need to force it. For most people this is just a heads-up that a hash generated on 5.6 with the 'b' prefix won't be able to be verified on an older system.

      http://www.openwall.com/lists/oss-security/2012/01/02/4 has more information about the problem. In a nutshell: by design, bcrypt truncates the input at 72 characters, so using a password longer than this doesn't increase strength, but if you use a longer password than this anyway, a wraparound bug affects certain lengths of longer passwords resulting in weak hashes.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]