Release outside of normal security process

Normally, our security process involves a one-week lead time for third parties on our security prenotification list. That process, however, relies on responsible disclosure practices which maintain confidentiality of a security issue until a coordinated public release date. To facilitate that, we ask that potential security issues always be reported via email to security@djangoproject.com, rather than through public channels such as Django's ticket tracker or the django-developers mailing list.

This issue, unfortunately, could not be handled by our normal process, as it was first reported publicly on the django-developers mailing list. It has since been confirmed by the Django core team, and due to the already-public nature of the issue and the potential to impact live deployments of Django, we are instead issuing security releases immediately.

Issue: denial-of-service via large passwords

Django's authentication framework -- django.contrib.auth -- includes a default User model and backend which authenticates via username and password. The raw password is not stored in the database; instead, a hashed version of the password is stored, and the hash is computed each time a user attempts to log in. The hasher to use is configurable, via the PASSWORD_HASHERS setting.

The default password hasher in Django is PBKDF2, which has the virtue of allowing the complexity of computing the hash to be effectively arbitrarily high, by repeated "rounds" of application before producing the final result. This increases the difficulty of attacks which use brute-force methods to compute the hashes of many possible plaintext values, in hopes of discovering which plaintext password corresponds to a given hashed value.

Unfortunately, this complexity can also be used as an attack vector. Django does not impose any maximum on the length of the plaintext password, meaning that an attacker can simply submit arbitrarily large -- and guaranteed-to-fail -- passwords, forcing a server running Django to perform the resulting expensive hash computation in an attempt to check the password. A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher.

This allows for denial-of-service attacks through repeated submission of large passwords, tying up server resources in the expensive computation of the corresponding hashes.

Although this is most effective against algorithms which are designed to be relatively "slow" to compute, such as PBKDF2 (which, again, is the default hasher in Django's authentication framework), it also is effective against other hashers, as the time to compute the hash generally grows with the size of the password.

To remedy this, Django's authentication framework will now automatically fail authentication for any password exceeding 4096 bytes.

Affected versions

• Django master development branch
• Django 1.6 (currently at beta status)
• Django 1.5
• Django 1.4

At the time of this writing, efforts are being made to obtain a CVE for this issue. This post will be updated with the CVE once it has been obtained.

Update: this issue was assigned CVE-2013-1443.

Resolution

Patches have been applied to Django's master development branch, and to the 1.6, 1.5 and 1.4 release branches, which resolve the issue described above. The patches may be obtained directly from the following changesets:

• master development branch
• 1.6 release branch
• 1.5 release branch
• 1.4 release branch and additional commit for Python 2.5 compatibility

The following new releases have been issued:

• Django 1.6 beta 4 (download Django 1.6b4 | 1.6b4 checksums)
• Django 1.5.4 (download Django 1.5.4 | 1.5.4 checksums)
• Django 1.4.8 (download Django 1.4.8 | 1.4.8 checksums)

General notes regarding security reporting

As always, we ask that potential security issues be reported via private email to security@djangoproject.com, and not via Django's Trac instance or the django-developers list. If you think you may have found a security issue but aren't sure, we urge you to err on the side of caution, and report via email rather than public channels. Please see our security policies for further information.