Date: Mon, 11 Jun 2012 12:43:43 +0100 From: "Simon L. B. Nielsen" <simon@FreeBSD.org> To: Gleb Kurtsou <gleb.kurtsou@gmail.com> Cc: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= <des@des.no>, freebsd-security@freebsd.org Subject: Re: Default password hash Message-ID: <CAC8HS2HFe87JU_x7vfbXP-_=WXJKv2kmG4sPBXxGgJ-k7-3poQ@mail.gmail.com> In-Reply-To: <20120610145351.GA1098@reks> References: <86r4tqotjo.fsf@ds4.des.no> <6E26E03B-8D1D-44D3-B94E-0552BE5CA894@FreeBSD.org> <20120610145351.GA1098@reks>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 10, 2012 at 3:53 PM, Gleb Kurtsou <gleb.kurtsou@gmail.com> wrot= e: > On (10/06/2012 11:02), Simon L. B. Nielsen wrote: >> >> On 8 Jun 2012, at 13:51, Dag-Erling Sm=C3=B8rgrav wrote: >> >> > We still have MD5 as our default password hash, even though known-hash >> > attacks against MD5 are relatively easy these days. =C2=A0We've suppor= ted >> > SHA256 and SHA512 for many years now, so how about making SHA512 the >> > default instead of MD5, like on most Linux distributions? >> >> Has anyone looked at how long the SHA512 password hashing actually takes= on modern computers? >> >> The "real" solution for people who care significantly about this seems s= omething like the algorithm pjd implemented (I think he did it at least) fo= r GELI, where the number of rounds is variable and calculated so it takes X= /0.X seconds on the specific hardware used. That's of course a lot more com= plicated, and I'm not sure if it would work with the crypt() API. > > Do you mean pkcs5v2_calculate from geli? It seems to have a drawback Correct. > that results produced depend on actual CPU load. That's not the drawback, but the whole point (well, at least a point). While it can of course produce fewer rounds on different systems, especially on fast systems you will likely end up with a lot more rounds than whatever the default is. > % ./pkcs5v-test [*] > 541491 > 539568 > 542352 > 540376 > 388285 -- start several instances of pkcs5v-test in parallel > 303071 > 284793 > 281110 > > It would be awesome to provide user with options to configure minimal > and maximal iteration count and randomly choose iteration count within > the range for each new password. Such trivial change should considerably > complicate mass password bruteforce cracking. That's also an option. I'm not sure how well that would work in practice. > Variable number of rounds for a password would also require changing > crypt() interface. Exactly, so probably not actually a working solution for normal case, and possibly just not worth the trouble at all due to compatibility. > Why does nobody mention scrypt? It looks very attractive in longer > perspective. It's not in the base system yet, last I checked anyway, so I assume that either Colin still don't find it ready for general use, or he has just been too busy. --=20 Simon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAC8HS2HFe87JU_x7vfbXP-_=WXJKv2kmG4sPBXxGgJ-k7-3poQ>