This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author hynek
Recipients Jon.Oberheide, alex, christian.heimes, fijall, georg.brandl, hynek, loewis, ncoghlan, petri.lehtinen, pitrou, python-dev, serhiy.storchaka
Date 2012-06-23.15:35:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <73651495-417A-4F18-8A2E-F969904D0390@ox.cx>
In-reply-to <1340464138.35.0.479623648128.issue15061@psf.upfronthosting.co.za>
Content
> For 3.4, I hope to see a discussion open up regarding the idea of something like a "securitytools" module that aims to provide some basic primitives for operations where Python's standard assumptions (such as flexibility and short circuiting behaviour) are a bad fit for security reasons. That would include exposing a C level full_compare option, as well as the core pbkdf2 algorithm.

Strong +1 on that one. We could even consider adding bcrypt and scrypt as C isn't really an issue for us.

Ideally we'd add a module with docs which both promote and leverage secure behavior. Basically how to realize http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html in Python.
History
Date User Action Args
2012-06-23 15:35:10hyneksetrecipients: + hynek, loewis, georg.brandl, ncoghlan, pitrou, christian.heimes, alex, fijall, python-dev, petri.lehtinen, serhiy.storchaka, Jon.Oberheide
2012-06-23 15:35:10hyneklinkissue15061 messages
2012-06-23 15:35:09hynekcreate