mailing list archives
Re: weird crypt-sha* in DragonFly BSD
From: "Samuel J. Greear" <sjg () thesjg com>
Date: Fri, 20 Jan 2012 12:22:51 -0700
1. You will want to be aware of this issue:
glibc crypt(3), crypt_r(3), PHP crypt() may use alloca()
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"
+ * In order to ensure that both existing passwords will continue to work
+ * 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? -
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
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
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?