This website does readability filtering of other pages. All styles, scripts, forms and ads are stripped. If you want your website excluded or have other feedback, use this form.

'bcrypt version changes' - MARC

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-misc
Subject:    bcrypt version changes
From:       Ted Unangst <tedu () tedunangst ! com>
Date:       2014-02-24 0:04:53
Message-ID: b24665a042f241fcb00a5f368397b5d3 () tedunangst ! com
[Download message RAW]

[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.

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic