Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Jul 2011 01:31:03 +0400
From: Solar Designer <solar@...nwall.com>
To: Ludwig Nussel <ludwig.nussel@...e.de>
Cc: oss-security@...ts.openwall.com, Michael Matz <matz@...e.de>,
	Thorsten Kukuk <kukuk@...e.de>, Andreas Jaeger <aj@...e.de>,
	Zefram <zefram@...h.org>
Subject: Re: CVE request: crypt_blowfish 8-bit character mishandling

On Thu, Jul 07, 2011 at 10:05:07AM +0200, Ludwig Nussel wrote:
> mkpasswd (package whois) checks whether the crypted password starts
> with the originally requested prefix. Since crypt_gensalt now
> returns $2y for $2a mkpasswd fails. I'm not claiming mkpasswd's
> assumption on the behavior of crypt_gensalt is correct but it's not
> documented whether crypt_gensalt may change the prefix.

Thank you for letting me know.  Yes, this prefix change in
crypt_gensalt*() was a hack, which I didn't give much thought yet.
It would have been nice to be able to switch to using $2y$ for
crypt_gensalt*()-aware apps (including our pam_tcb) just by upgrading
glibc, without changes to any other component nor to a config file, but
I agree that we'll want to avoid surprises like that.  I'll change my
code to preserve the requested prefix.

Another idea that I haven't given much thought yet is to encode, say, a
64-bit magic constant in the salt (leaving the remaining 64 bits out of
the total of 128 for the actual salt), indicating that this is a newly
generated "setting" string and enabling crypt(3) to treat $2a$ as $2y$
safely.  Or we could in fact fully use this instead of $2y$, although
that would reduce the salt space for all - not really a problem since
128 bits for a crypt(3) salt was excessive, but it doesn't sound good.
This would have the advantage of being 100% compatible with OpenBSD's
$2a$ hashes, including usage of the $2a$ prefix, yet carrying the
desired extra bit for us.  There's only a very slight chance of someone
else's salt string inadvertently having our magic constant in it, which
would exclude the hash from collision protection against hashes of the
buggy algorithm.  A drawback: this fails if a new version of
crypt_gensalt*() is used with an older version of the hashing code (with
the sign extension bug in it).  $2y$ protects from that (the old code
would refuse to process such "setting" strings).

Alexander

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.