Re: weird crypt-sha* in DragonFly BSD

["Samuel J. Greear" <sjg () thesjg com>]

> 1. You will want to be aware of this issue:
>
> glibc crypt(3), crypt_r(3), PHP crypt() may use alloca()
> http://www.openwall.com/lists/oss-security/2011/11/15/1
>
> There's no agreed upon fix yet (use "thread-next" to see some ideas),
> but I think all distros/projects using Ulrich's SHA-crypt will need to
> deal with this issue eventually.  I'll try to remember to inform you
> once we choose to do anything specific.

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.



> 2. Instead of:
>
> + * The deprecated sha256/512 functions are somehow sensitive to the
> + * order of this crypt_types array as well as their respective "name"
> members.
> + *
> + * In order to ensure that both existing passwords will continue to work
> and
> + * that new passwords will be more secure by using the new algorithms even
> + * without updating the existing login.conf, this array is now scanned
> + * backwards. This could be reverted in the future when the deprecated SHA
> + * functionality is removed.
>
> how about using the more reliable approach proposed by magnum here? -
>
> http://www.openwall.com/lists/john-dev/2012/01/19/1
>
> As you can see, he has even spent time to identify the specific 64-bit
> magic values.  Of course, you'll need to double-check them (such as by
> applying the patch and testing logins to existing accounts with both
> sha256 and sha512 on a 64-bit DragonFly system.)
There isn't a collision issue with $3$ and $4$ on DragonFly, so I don't see
any obvious need. I intend to rip the old code out after a few releases, so
the issue (if there is one) will be (relatively) short lived.


> 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
> that you can use for this?  sha256 no longer means the same thing
> anyway; there's no good reason for a percentage of DragonFly systems to
> temporarily switch from one SHA-256 based algorithm to another just for
> them to hopefully switch to sha512 a little bit later (when the admin
> does that).  And, what's worse, many systems will end up stuck in this
> intermediary state.
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?

Thanks,
Sam