On Sat, Sep 10, 2011 at 11:54 AM, Paul McMillan <[email protected]> wrote: > In conjunction with Justine Tunney, Isaac Kelly and Russell KM, I'd > like to introduce our plan of attack for including significantly > better password hashing in Django 1.4. One of the key goals with this > push is to include just enough functionality that we can improve this > particular aspect of Django. There's a lot of other great work that > could happen as part of a more general contrib.auth overhaul, but we > want to change as little as possible so we can get a patch out quickly > (in time for the 1.4 feature freeze). > > The default password hashing algorithm will be changed to PBKDF2. > We'll include a pure python implementation, but preferably load faster > versions if available at the system level.
Preferentially, not preferably - but otherwise +1 :-) > Password hashing will happen via pluggable backends that implement the > set_password() and check_password() methods on the current User model. > We're considering trying the generic backend module from armstrong for > this, with the idea that we can move our other adhoc backend > implementations to a unified generic module in the future. It's worth pointing out that this can -- and probably should -- be handled as a two-step process. Step one is to get PBKDF2 support into trunk. Step two is a cleanup of the way backends are handled in general. This is a larger code cleanup exercise, and a worthwhile one; but the decision to refactor Django's backend loading code is orthogonal to the need to add PBKDF2 support. It's also worth noting that we already have a pluggable backend to use here -- auth is already a backend-based system. It requires some refactoring to get the password checking code into the backend rather than being user-based, but that's a relatively small modification of the existing codebase. > We will include backends that implement all the existing hashing > schemes as well as an optional module for bcrypt that uses a system > library if available. We will work to provide a clean upgrade path for > users of django-bcrypt. > > We will be extending the current system that allows users to upgrade > their password algorithms in place. We recognize that sysadmins may > change their mind about which algorithm they prefer (for example, if > PBKDF2 becomes more overhead than they like, or they decide to upgrade > from SHA1). We want people to be confident in trying the new hashing > algorithms, so we will provide a mechanism for choosing a preferred > hashing backend and converting passwords to that backend as they are > used. > > We're looking at ways to mitigate the effects of DoS attacks against > the auth module due to the higher CPU usage for these new backends. > Suggestions on this topic are welcome, but will probably be > implemented as part of a separate commit. > > I'm really excited that we finally have the momentum to bring this > important change to Django! Likewise; +1 to the general thrust, and for getting this into 1.4 Russ %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
