On Mon, Feb 21, 2011 at 9:26 AM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > 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.
At Mozilla we've been trying to work out our ideal password storage scheme for a little while. Spoiler alert: it doesn't involve bcrypt. There's no code yet, but we have a little bit of documentation here: https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Password_Storage. This is the outline: 1. sha512 hashing 2. Per-user salt stored with the hashed password 3. Private system salt stored outside the database 4. The system salt can be deprecated if it gets leaked 5. Required minimum password length 6. Common passwords are blocked 7. Migrations towards more security are possible as long as you have code to unwrap the migration I've cc'd Michael Coates (our security guy) since he can provide more background on why we're moving towards this strategy. Basically, if people are using weak passwords, switching hashing schemes is not going to provide much more protection. If it takes 0.3 seconds to encrypt "pa$$word" then it took 0.3 seconds, but I still have your user's password. We're trying to structure a system that provides more entropy and prevents weak passwords altogether. -- 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.
