Re: weird crypt-sha* in DragonFly BSD

[Solar Designer <solar () openwall com>]

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

Alexander