BCrypt password hashing support in Django

[Erik Karulf]

About the bcrypt algorithm

• The algorithm is designed to replace traditional password hashing algorithms by the OpenBSD group
• The algorithm is significantly more secure than traditional crypt, md5 and sha1 hashing algorithms
• The algorithm manages salt generation automatically
• The algorithm allows for user configurable levels of algorithm complexity, allowing the algorithm to grow in complexity to match growth in CPU speeds
• Links:
  • OpenBSD Whitepaper on bcrypt : ​bcrypt-paper.ps
  • py-bcrypt : ​project home page
  • Review of password storage by Matasano security group: ​review

About the patch

• The patch introduces no backwards incompatible changes
• The patch allows for use of the bcrypt algorithm iff the bcrypt module is available
• The patch introduces two new settings :
  • PREFERRED_HASH - The preferred hash algorithm for storing passwords (default: 'sha1')
  • BCRYPT_LOG_ROUNDS - The number of rounds determines the complexity of the bcrypt algorithm (default: 12)
• The patch moves the encryption formats out of the user model entirely
• The patch has been tested against Python 2.4 / OS X (10.4)
• The patch updates the relevant documentation according to the style guidelines

[Erik Karulf]

First revision of django-bcrypt patch

[James Bennett]

Feels like a more specific case of #5600; "add a specific algorithm" really is a subset of "improve the support for different algorithms".

[Malcolm Tredinnick]

By the way, this sort of patch is backwards incompatible: as soon as you start generating passwords that are only computable based on an optional model, the database can only be used with Django installations that have that model available. This removes the ability to move the database around easily. Django operates on a "batteries included" philosophy for exactly that reason: runs anywhere without lots of extra dependencies.

[Erik Karulf]

I meant to say compatibility in the API sense and I apologize for the confusion. If a user were to change their default hash, install the bcrypt module, and then move their data to a new environment where bcrypt is not available, it would not allow their users to authenticate.

That said, this seems somewhat inconsistent with the decision in ticket #3316. The crypt module has the same dump/restore constraints and includes an additional constraint of restricting the operating system to unix environments. My goal is not to re-open the ticket nor be argumentative, but I am new to the django community and I am trying to get a sense of the framework.