Date: Sat, 21 Jan 2012 00:35:52 +0400 From: Solar Designer <solar@...nwall.com> To: "Samuel J. Greear" <sjg@...sjg.com> Cc: dillon@...llo.backplane.com, Nolan Lum <nol888@...il.com>, security@...gonflybsd.org, oss-security@...ts.openwall.com, magnum <john.magnum@...hmail.com> Subject: Re: weird crypt-sha* in DragonFly BSD 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
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.