On Mon, Feb 21, 2011 at 3:23 PM, poswald <paulosw...@gmail.com> wrote: > Russ, Carl, thanks for your feedback. Russ, I understand what you say > about not wanting to adopt crypto code because of the additional > responsibility. Unfortunately, there aren't very good options. Django > contrib.auth already makes the recommendation of SHA1 which we all > agree is less than ideal. There is simply no acceptable choice in the > python standard library. I also agree with Carl that PBKDF2 is > probably the most conservative option that qualifies as sufficient.
I've been desperately trying to get up to speed on this stuff over the past few weeks. Crypto's very far from my strong suit, but I think I know enough now to agree. It seems to me we need two things: 1. A new, updated default for Django's password hashing. PBKDF2, perhaps, but whatever as long as it meets some basic requirements. 2. A mechanism to make swapping this hashing algorithm out easy(-ier). Again, details don't matter, requirements do. #1's a blocker for 1.4, I think, but if for some reason #2 can't be figured out I think it's ok to punt there for a bit longer. Ideally though they'd both go in at once. Now, I want to make very explicit my requirements here since we've gone 'round on this one a few times, so I'll lay out exactly what I'm going to want to see to get on board with any proposal. So: Requirements for a new password hash: * As little crypto code in Django as possible. We're not security experts, and we shouldn't try to be. Ideally would be something that leaves all of the dangerous parts to the stdlib. Perhaps we relax our dependency policy (we need to some day, I think, but that's a bigger argument maybe we shouldn't have now). * Any code we distribute gets audited by people who know what they're talking about. * Those people have reputations sufficient to convince me (or other core devs) that they know what they're doing. This is sorta a "who watches the watchers" moment, but we can't just trust someone who says they're a crypto expert; we have to believe them, too. Requirements for pluggable hashing algorithms: * The big one is cross-installation password compatibility. If I upgrade from Python 2.4 to 2.7 my passwords have to keep working. If I install django-bcrypt my old passwords have to keep working. If I then decide to switch to pbkdf2 my bcrypt passwords have to keep working. We already have an in-place upgrade mechanism for md5; we probably need something similar as a generic thing. * Failures need to be clear - I shouldn't get mysterious login failures if I accidentally uninstall bcrypt (i.e. I should get a loud, clear, failure quickly). * We need an internal upgrade path that *we* can use when a few years from now everyone starts complaining that PBKDF2 is fundamentally flawed and that we're total idiots for clinging to it. [It occurs to me that, with the right mentor, this would make a fantastic SoC project...] Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
