Re: [OSSN-0081] sha512_crypt is insufficient for password hashing

[Jeremy Stanley <fungi () yuggoth org>]

On 2017-09-17 15:04:10 +0200 (+0200), Solar Designer wrote:
[...]
> 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.

Yes, or more specifically these:

https://passlib.readthedocs.io/en/stable/lib/passlib.hash.sha512_crypt.html
https://passlib.readthedocs.io/en/stable/lib/passlib.hash.pbkdf2_digest.html

> 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

Thanks for the pointer! I wasn't familiar with the fastpbkdf2 talk,
definitely some helpful research there.

> 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.
[...]
> 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.

I must admit, the confusion was probably primarily mine. When asked
for feedback on the earlier bug report, I mistook the description at
face value assuming that "sha512 based password hashing" referred to
a raw one-way hash function along the lines of hashlib.sha512(), and
spouted the usual recommendation for using a KDF instead of a bare
hash:

https://launchpad.net/bugs/1543048

Had I instead taken the time to look at the existing implementation
in the source tree (as I would have done were it flagged for a
formal advisory) I would have probably noticed that it already was
using a KDF... tunnel vision on my part perhaps. I've added a
comment to this effect on the bug report linked from the security
note and will write up some appropriate errata to accompany it.

Thanks for noticing and pointing out this error, and my apologies
for any inconvenience my lack of attention may have caused.
-- 
Jeremy Stanley

Attachment: signature.asc
Description: Digital signature