add compatibility with glibc2 MD5-based crypt passwords

[Antti Kaihola]

In [5073] support for Unix DES crypt passwords was added (see #3316 for discussion).

Many systems use MD5-based crypt shadow passwords (see e.g. man 3 crypt or its ​on-line version, under heading "GNU Extension"). This extension to the crypt library prefixes the encrypted password with "$1$<8-character-salt>$" instead of the 2-character salt.

Django uses dollar signs ($) to delimit the algorithm, salt and encrypted password in the contrib.auth.models.User.password string. The choice of delimiter collides with glibc2 crypt. Apart from that MD5 crypt passwords should just work with the current code.

I bumped into this in a project where I need to move a number of Linux user accounts along with their passwords to Django.

The first solution which comes to mind is to add another algorithm name, e.g. "md5-crypt", and add its own splitting parser to replace ​the current one.

[Antti Kaihola]

use "crypt" as name for both DES and MD5 crypt algorithms and detect MD5 by examining the salt

[Antti Kaihola]

algorithm name must be explicitly set to "md5-crypt" for MD5 crypt passwords; salt must still start with $1

[Antti Kaihola]

detect MD5 crypt passwords by checking if salt begins with "$1" for both "md5-crypt" and "crypt" as algorithm name

[Antti Kaihola]

The above three alternate patches offer three different conventions for specifying MD5 crypt passwords.

The first one​ doesn't add a new algorithm name. It detects and correctly parses MD5 crypt passwords when the salt part of the password string starts with "$1".

The second one​ adds "md5-crypt" as a new algorithm name, and MD5 crypt passwords must use it.

The third one adds the "md5-crypt" algorithm name, but also auto-detects MD5 crypt passwords when "crypt" is used as the algorithm name.

[Simon G <dev@…>]

akaihola - can you raise this on django-dev?

[Antti Kaihola]

Simon, done: ​http://groups.google.com/group/django-developers/t/9a01b37affe11fe6

[Philipp Wollermann]

I'd like to raise this one again - as far as I can see, these patches still apply cleanly to trunk and provide some nice functionality with regards to exchanging Django authentication credentials with Linux authentication. Was there a reason for not accepting the patch?

[Antti Kaihola]

#9194 is somewhat related (allow additional hashing algorithms for passwords).

[Alex Gaynor]

While we don't have it yet, Paul McMillan and others are working on a more proper infrastructure for allowing different password hashing schemes. This will be able to live outside Django once it lands, and thus no action should be taken inside Django for this.