[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
