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

[Guido van Rossum]

On Mon, Jun 11, 2012 at 1:08 PM, Masklinn <masklinn at masklinn.net> wrote:
> 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.

Is there any indication that Python was involved in last week's
incidents? (I'm only aware of the Linkedin one -- were there others?)

> 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?

Do you really think that including some API in the stdlib is going to
make a difference in education? And what would we do if in 2 years
time the stdlib's "basic functionality" were somehow compromised (not
due to a bug in Python's implementation but simply through some
advance in the crypto world) -- how would we get everyone who relied
on the stdlib to switch to a different algorithm? I really think that
the right approach here is to get *everyone* who needs this to use a
3rd party library. Diversity is very good here!

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

TBH it's possible that I'm not sufficiently familiar with the issue to
have a valid opinion here -- I would never dream of taking on the
responsibility of password security for anything, since I don't have
the right crypto hacker mindset. But I do worry about having
attractive suboptimal solutions to common security problems in the
stdlib.

-- 
--Guido van Rossum (python.org/~guido)