On Sun, Jun 10, 2012 at 3:53 PM, Gleb Kurtsou <gleb.kurt...@gmail.com> wrote: > On (10/06/2012 11:02), Simon L. B. Nielsen wrote: >> >> On 8 Jun 2012, at 13:51, Dag-Erling Smørgrav wrote: >> >> > We still have MD5 as our default password hash, even though known-hash >> > attacks against MD5 are relatively easy these days. We've supported >> > 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 >> something like the algorithm pjd implemented (I think he did it at least) >> for 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 >> complicated, 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. -- Simon _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
