Date: Sun, 17 Sep 2017 15:04:10 +0200 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: [OSSN-0081] sha512_crypt is insufficient for password hashing 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 https://bugs.launchpad.net/ossn/+bug/1668503 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: https://jbp.io/2015/08/11/pbkdf2-performance-matters 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: http://www.openwall.com/lists/john-users/2017/06/25/1 http://www.openwall.com/lists/john-users/2017/07/03/4 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
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ