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

[Eli Collins]

Christian Heimes <lists at ...> writes:
 
> Am 11.06.2012 22:21, schrieb Guido van Rossum:
> > 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!
> 
> +1
> 
> I'm against adding just the password hashing algorithms. Developers can
> easily screw up right algorithm with a erroneous approach. It's the
> beauty of passlib: The framework hides all the complex and
> easy-to-get-wrong stuff behind a minimal API.
> 
> Christian
> 

I know I'm a little late to this thread, but as the primary Passlib author, I
wanted to throw in my two cents.

I wholeheartedly agree with the idea of not having a high-level password hashing
library in stdlib. I'd be honored and happy to help in extracting a subset of
passlib for inclusion in the standard library. However, for all the reasons GvR
pointed out, I'm scared at the thought of how slowly end deployments would get
needed security updates (for one thing, I update the adaptive cost of the hashes
in passlib about once a year just as a matter of course). I'm reminded of how
the Debian project has had to create a "security" repository to supplement the
"stable" repository, just so the slow-moving "stable" release gets timely
security updates.

All that said, I wouldn't mind seeing a pbkdf2() primitive added to stdlib,
along the lines of M2Crypto's pbkdf2 function [1]. I agree such a function might
mislead developers to roll their own password hashing routines, but a word of
warning and redirection in the documentation might help with that. The reason I
see a need for such a function is that all existing password hashing libraries
(passlib, cryptacular, flufl.password, django.contrib.auth.hashers, etc) have
had to roll their own pure-python pbkdf2 implementations, to varying degrees of
speed. And speed is paramount for pbkdf2 usage, since security depends on
squeezing as many rounds / second out of the implementation as possible. 

Having a single C-accelerated primitive would be great for all of the above
libraries, and all the other uses pbkdf2 has. Furthermore, it wouldn't need
frequent security updates, since the hash storage format, default cost, default
digest, etc, would all be handled by the higher-level libraries. Not that I'm
advocating such a thing is *needed*, but that's what I'd love to see, were
anything to be added in this direction. 

Hope all that helps in your decision making.

Thanks,
Eli

[1] http://www.heikkitoivonen.net/m2crypto/api/M2Crypto.EVP-module.html#pbkdf2

- Eli Collins