Default password hash

[Simon L. B. Nielsen]

On Sun, Jun 10, 2012 at 3:53 PM, Gleb Kurtsou <gleb.kurtsou at 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