Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 18 Sep 2017 14:00:09 -0400
From: Jordan Glover <>
To: "" <>
Subject: Re: [OSSN-0081] sha512_crypt is insufficient for password hashing

What number of iterations is considered secure for sha512crypt/pbkdf2 these days?

> -------- Original Message --------
> Subject: Re: [oss-security] [OSSN-0081] sha512_crypt is insufficient for password hashing
> Local Time: September 17, 2017 1:04 PM
> UTC Time: September 17, 2017 1:04 PM
> From:
> To:
> On Sun, Sep 17, 2017 at 12:27:41PM +0100, Luke Hinds wrote:
>> Keystone uses sha512_crypt for password hashing. This provides
>> insufficient and limited protection, since sha512_crypt algorithm has a
>> low computational cost factor, therefore making it easier to crack
>> passwords offline in a short period of time.
>> The correct mechanism is to use the more secure hashing algorithms with
>> a higher computational cost factor such as bcrypt, scrypt, or
>> pbkdf2_sha512 instead of sha512_crypt.
>> ### Recommended Actions ###
>> It is recommended that operators upgrade to the Pike release where all
>> future passwords would be bcrypt hashed.
> The move to bcrypt makes sense as a defense against GPU attacks, which
> are currently most relevant. I would have recommended it, too.
> However, the wording of the advisory and in the discussion at
> is weird.
> I assume that sha512_crypt refers to the algorithm introduced in glibc
> 2.7 and now used by many Linux distros and more. It is typically called
> sha512crypt without the underscore. I also assume that pbkdf2_sha512
> refers to PBKDF2-HMAC-SHA512.
> sha512crypt"s "computational cost factor" is tunable, and sha512crypt
> isn"t quicker to crack than PBKDF2-HMAC-SHA512 when both are tuned for
> the same defensive running time and use implementations optimized to a
> similar extent. However, PBKDF2-HMAC has worse missed optimization
> pitfalls, so highly unoptimal implementations of PBKDF2 are very common:
> Obviously, password crackers may use more optimal implementations.
> I guess the names with underscores are some specific instantiations with
> fixed cost factors? I guess bcrypt and scrypt referred to here are also
> specific instantiations with fixed cost factors? Then the wording would
> start to make sense. For completeness, what are the specific cost
> factors used for each of those four?
> Reading the discussion on relevant Bug entries and proposed commits, it
> appears that pbkdf2_sha512 was recently introduced under the flawed
> understanding that "sha512_crypt is considered insufficient (even with
> significant rounds) in comparison to pdkfd_sha512, bcrypt, or scrypt for
> password hashing." While the references to bcrypt and scrypt are
> correct, the reference to (presumably) PBKDF2-HMAC-SHA512 is wrong. It
> is in the same category with sha512crypt. As it is, pbkdf2_sha512 might
> very well allow for quicker cracking than sha512_crypt does. Without
> knowing the specific settings and efficiency of implementations, we
> can"t tell.
> Then, Bug 1668503 lists FPGAs as part of the motivation for the change.
> However, bcrypt fits FPGAs very well:
> The move from sha512crypt to bcrypt is good against GPUs, but makes
> little difference against FPGAs. It"s still a fine move to take now -
> it is an improvement, and GPU attacks are more relevant. You just need
> to know what you achieve (GPU attack resistance) and what you don"t
> achieve (FPGA attack resistance).
> Of the four algorithms, only scrypt (and only at high enough settings)
> is somewhat FPGA attack resistant by requiring external memory and
> memory bandwidth, which has to be part of the attack platform"s cost.
> I don"t recommend any further code changes at this time. Rather, I
> recommend that the confusion be dealt with: clarify the settings used,
> don"t refer to pbkdf2_sha512 as a clear improvement upon sha512_crypt.
> Alexander

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ