Message163630
| 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:10 | hynek | set | recipients: + hynek, loewis, georg.brandl, ncoghlan, pitrou, christian.heimes, alex, fijall, python-dev, petri.lehtinen, serhiy.storchaka, Jon.Oberheide |
| 2012-06-23 15:35:10 | hynek | link | issue15061 messages |
| 2012-06-23 15:35:09 | hynek | create | |