Home page logo

oss-sec logo oss-sec mailing list archives

Re: weird crypt-sha* in DragonFly BSD
From: Solar Designer <solar () openwall com>
Date: Sat, 21 Jan 2012 00:35:52 +0400

On Fri, Jan 20, 2012 at 12:22:51PM -0700, Samuel J. Greear wrote:
I saw this, my preference would be to get rid of all uses of alloca() and
use malloc(), optionally with a fixed-size array on the stack for short
passwords. If specific alignment is needed it can be forced by
over-allocating and indexing into the heap allocation to the correct
alignment. (I have a personally vendetta against alloca(), importing new
uses of it made me cry a little) -- So I may do this, but it doesn't make
my short list, if someone beats me to it I would be interested in hearing
about it so we can keep in sync.

Thank you for stating your preference.

No manual alignment like you describe should be needed with malloc() -
it is supposed to return a pointer that is already suitably aligned.

3. It would be nice for upgraded systems to automatically switch from
sha256 to sha512 in login.conf - perhaps there's some on-upgrade hook

We do not have specific infrastructure for this and it needed to work for
any systems stuck in such an intermediary state anyway, but I will be
looking into what we can do to a) automatically change the setting in
login.conf and b) warn users/administrators of their existing potentially
insecure passwords.

An aside on B above, if we do put in place a mechanism to warn users/admins
about passwords with $3$ and $4$ magic, is the MD5 implementation
sufficiently weak at this point to warrant warning about it as well?

For "md5", I think it'd be more appropriate to inform (rather than warn)
the administrators (only) of availability of a more modern and more
secure option.  You may reuse the same code that you'd introduce for
dealing with $3$ and $4$, but use slightly different wording of the
warning message and not display it to non-root users (only display it to
root if the default for new passwords is weaker than the new sha512).

The known cryptographic weaknesses of MD5 are irrelevant to its use for
password hashing.  Thus, the only relevant weakness is in the lower
computational complexity: 1000 iterations of MD5 vs. approx. 17,000
iterations of SHA-512 for typical password lengths (with the default
setting of rounds=5000).  This may be a 50x difference in cracking speed.

I think that moving to bcrypt would be better.  Both MD5-crypt and
SHA-crypt are GPU-friendly, whereas bcrypt is not.

SHA-crypt's advantage over bcrypt is political: it can be said that it
builds upon a NIST-approved algorithm.  I don't know whether you find
this important for your project (so important that you'd sacrifice some
actual security to gain this) or not.

(Indeed, it is possible to do better than bcrypt with knowledge of
present threats, but we're talking password hash types that are already
in use.)


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]