Raw password echoed on authentication if no hashing used

[Daniel Roseman]

If a password is somehow created without being hashed - say by the developer setting user.password directly rather than via set_password - the check_password function wrongly assumes that the entire password is the hashing algorithm, and passes it to get_hasher, resulting in an error message which reveals the actual password:

>>> user = User.objects.create(username='foo', password='bar')
>>> authenticate(username='foo', password='bar')
...
ValueError: Unknown password hashing algorithm 'bar'. Did you specify it in the PASSWORD_HASHERS setting?

The bug is in django.contrib.auth.hashers.check_password, line 41, where it assumes that the result of encoded.split('$', 1)[0] will always be an algorithm, when in the above case it's the password itself.

Although the password shouldn't have been created in this way in the first place, the code in check_password should be more intelligent about whether or not it's found an algorithm name.

[Aymeric Augustin]

Since this may lead to leaking sensitive information, I suppose Django should test if the string contains at least a $ character, and complain that it doesn't look like a password hash otherwise.

[Moritz Sichert]

Added patch (​Github Pull Request)

contrib.auth.hashers.is_password_usable now checks if the encoded string contains a $ character. For backward compatibilty to unsalted md5 hashes all encoded 32-character-long strings without a $ character are assumed to be usable. check_password won't return True for a 32-character-long plain password, though.

[Claude Paroz]

Updated and using identify_hasher

[Claude Paroz]

hashers.py does now contain a identify_hasher function. In this patch, I suggest to use this function in is_password_usable.

[Claude Paroz]

The current problem with altering is_usable_password is that the error message "Invalid password format or unknown hashing algorithm" is not displayed in the user change form. This should be addressed.

[Claude Paroz]

Proper display in ReadOnlyPasswordHashWidget

[Claude Paroz]

Now ReadOnlyPasswordHashWidget is still displaying an error message if encoded is not valid.

[Claude Paroz]

Note to self: "Unusable password, the user cannot login." should probably simply be "No password set."

[robertomaurizzi]

What is the recommended way to fix an auth_user table full of "non passwords" as created following the provided code sample for an external authentication handler from ​https://docs.djangoproject.com/en/dev/topics/auth/#writing-an-authentication-backend ?
I'm planning to migrate an application to 1.4.1 and all my users have a 'nice' "password read from legacy_passwd table"...
What is the correct procedure to set all users without a valid password to an invalid password? Moreover: it'd be nice to update the sample for about external authentication... :-)

[Karen Tracey]

Replying to robertomaurizzi:

What is the recommended way to fix an auth_user table full of "non passwords" as created following the provided code sample for an external authentication handler from ​https://docs.djangoproject.com/en/dev/topics/auth/#writing-an-authentication-backend ?
I'm planning to migrate an application to 1.4.1 and all my users have a 'nice' "password read from legacy_passwd table"...
What is the correct procedure to set all users without a valid password to an invalid password? Moreover: it'd be nice to update the sample for about external authentication... :-)

Is this question related to this ticket? The ticket seems to be about Django possibly revealing a plain-text password if an auth backend has incorrectly stored a plain-text password in the password field. In your case it sounds like you have an innocuous string stored in your password fields. Also I'm not sure why upgrading to 1.4.1 is going to cause these to be a problem, unless you are also simultaneously getting rid of your custom authentation backend?

It's easy enough to change all the passwords to something more officially unusable:

Python 2.7.2+ (default, Oct  4 2011, 20:03:08) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from django.contrib.auth.models import User
>>> from django.contrib.auth.hashers import UNUSABLE_PASSWORD
>>> User.objects.filter(password='password read from legacy_passwd table').update(password=UNUSABLE_PASSWORD)

I suppose the referenced doc could be updated to use the "official" unsuable password, but I'm missing the reason why what's there now causes a problem. And I'm not sure adjusting that doc has anything to do with this ticket.

[robertomaurizzi]

You're right, I should have described the connection :-)

My problem is indirectly related to this ticket, since #18453 'Unknown password hashing algorithm error if password is blank' actually describe my problem (error if no $ in the password field) and it's stated that 'This should be fixed if current patch of #18182 is committed, however let this one open until then.'.

This happens because 1.4 introduced support for multiple hashes and it seems that something is checking for the hash signature even if I'm using a custom authentication backend.

Setting the passwords to UNUSABLE_PASSWORD (a '!') works, so problem solved (and... documented).
I agree the docs should be updated with the correct unusable password. Is there an official way to ask for this?

[Claude Paroz <claude@…>]

In 703c266682be39f7153498ad0d8031231f12ee79:

Fixed #18182 -- Made is_usable_password check if hashing algorithm is correct

The display of the ReadOnlyPasswordHashWidget has also been improved to
distinguish empty/unusable password from erroneous password.
Fixed #18453 also.
Thanks danielr and Leo for the reports and Moritz Sichert for the
initial patch.