mailing list archives
Re: *BSD's DES-based crypt(3) treats all invalid salt chars as '.'
From: Solar Designer <solar () openwall com>
Date: Mon, 2 Jan 2012 04:18:41 +0400
Christos Zoulas merged the relevant ones of my FreeSec code changes into
NetBSD, for NetBSD 6. Thus, starting with NetBSD 6, its crypt(3) will
have almost the same semantics for invalid two-character salts that
recent PHP's crypt() and UFC-crypt in glibc do.
Other *BSDs are welcome to merge these changes, too.
On Tue, Nov 15, 2011 at 07:54:04AM +0400, Solar Designer wrote:
The traditional DES-based crypt(3) accepts a salt string consisting of
characters from a certain base-64 alphabet, normally encoding a 12-bit
salt value in two characters.
What happens when the salt string contains characters outside of the
usual base-64 alphabet is implementation-specific. Typically,
implementations map those invalid salts onto the 12-bit values in one of
several ways. FreeSec, an otherwise very good implementation by David
Burren, appears to be the only widespread implementation that maps all
invalid salt characters onto just one 6-bit value - zero. FreeSec is
the implementation used by FreeBSD, OpenBSD, DragonFly BSD. The code in
NetBSD is different, but it appears to share this problem. Indeed,
these systems don't use the DES-based hashes by default, and even if
they did they'd be OK because they'd use valid salts, but the issue here
is with third-party programs that are not as careful - especially web
apps invoking this code via PHP's crypt() (whether the underlying
system's crypt(3) or PHP's own code is used depends on PHP version and
Thus, with poorly written programs combined with this property of
crypt(3) on *BSD's we get effectively matching salts, which a password
cracker aware of this property can take advantage of for much faster
I patched the FreeSec code to match UFC-crypt's handling of invalid
salts about 20 months ago:
This did not matter much for Owl because we do not actually override
glibc's UFC-crypt for the traditional hashes (we use FreeSec for
"extended" hashes with 24-bit salts, which are not produced by naive
apps), however I made those changes primarily for reuse of the code in
PHP - and the changes went into a certain version of PHP (5.3.2+, IIRC).
Now I welcome *BSD's to reuse these as well. Yes, this sort of breaks
compatibility with existing invalid-salt hashes produced on those
systems, but those will be easy to fix if necessary by explicitly
changing their invalid salt characters to '.' (and thus making the
problem even more apparent).