[Python-ideas] Add adaptive-load salt-mandatory hashing functions?

[Masklinn]

On 2012-06-11, at 18:49 , Guido van Rossum wrote:

> On Mon, Jun 11, 2012 at 3:03 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> However, password hashing is an important and common enough problem
>> that it would be good to have some basic level of support in the
>> standard library, with a clear migration path to a more feature
>> complete approach like passlib.
> 
> I usually like this approach, but here I am hesitant, because of the
> cost if the basic approach is found inadequate. The stdlib support
> should either be state-of-the art

Well depends what you mean by "state of the art", PBKDF2 is still the
"tried and true" trusted password-hashing algorithm (it's the one used
in TrueCrypt, 1Password, WPA2, DPAPI and many others). bcrypt is the
"old newness", working on the same principle as PBKDF2 (do lots of work)
but a different underlying algorithm, and scrypt is the "new newness" as
it includes being memory-hard on top of being processing-hard, but is
significantly less trusted as it's only a few years old.

So as far as I know, PBKDF2 is indeed "state of the art", scrypt is
"bleeding edge" and bcrypt is somewhere in-between[0] (but if PBKDF2 is
found to be insufficient, bcrypt will fall for similar reasons: it's
only binding on CPU power and is easy to parallelize). Ulrich Drepper
also built an MD5crypt-inspired crypt based on SHA2 (and fixed a few
weak ideas of MD5crypt[1]) a few years ago.

As a matter of facts, passlib notes PBKDF2/SHA512 as one of its three
recommendation (alongside bcrypt and sha512_crypt) and notes it is the
most portable of three roughly equivalent choices[2] (and that
sha512_crypt is somewhat baroque and harder to analyze for flaws than
the alternatives).

> or so poor that people are naturally
> driven to a state-of-the art alternative on PyPI that is maintained
> regularly. In this case I think our only option is the latter. I do
> think it is another example of a situation where the stdlib docs ought
> to contain some hints about where to go instead for this
> functionality.

The issue with this idea is that people are *not* driven to
state-of-the-art alternatives because they don't understand or know the
issue. And as a result, as we've seen last week, they'll use
cryptographic hashes (with or without salts) even though those are
insufficient, because that's available and they read on the internet
that it was what they needed.

And how are you going to make people understand there's a difference
between a cryptographic hash and a password hash by doing nothing,
giving them cryptographic hashes and leaving them to their own devices?

[0] and beyond the bleeding edge lies ubiquitous 2-factor auth,
    probably.
[1] MD5crypt can not use adaptive load factors and injects constant
    data at some points, it also allows longer salts.
[2] http://packages.python.org/passlib/new_app_quickstart.html#recommended-hashes