PASSWORD_HASHERS Check

[Francisco]

I think it would be a good idea to add a check for insecure hashers on PASSWORD_HASHERS[0], I know the insecure ones are not enabled by default, but I think it would be useful to warn users that have enabled them that it's a bad idea.

They could have enabled them on production while thinking they only enabled them for testing for example.

[Tim Graham]

For context, Francisco proposed this at https://code.djangoproject.com/ticket/33793 which was marked wontfix by Mariusz with the comment:

>  Django keeps "weak" password hashers for support with legacy systems and ​speeding up the tests. Moreover they are not enabled by ​default, so you must add them explicitly to the PASSWORD_HASHERS. Folks that do this should be aware of their weakness. IMO there is not need for a new system check.

Francisco, have you seen this mistake made? It doesn't seem very likely to me. Typically, the setting is customized in a test settings file; thus, I don't see how this could propagate to a production environment.

[Francisco Couzo]

If you happen to be using pytest and want to detect if you're testing, there's a really bad recommendation on this ticket: https://github.com/pytest-dev/pytest-django/issues/333, now that alone works, but if you were to import pytest, you would be running some test settings and be none the wiser.

Also I think it's a good practice, you could have modified PASSWORD_HASHERS years ago, and the hasher that was once secure is not any more.

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/CBdwSCiDKwY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4632834e-7864-48a9-947b-61aa0ccb11d6n%40googlegroups.com.

[Francisco Couzo]

Here is a real-world example I found on a quick search: https://github.com/dimagi/commcare-hq/blob/6be7be39cb3f554670685e811a15720d46cc4a2d/settings.py#L192

[Tim Graham]

On Friday, June 24, 2022 at 10:14:48 PM UTC-4 Francisco wrote:

Here is a real-world example I found on a quick search: https://github.com/dimagi/commcare-hq/blob/6be7be39cb3f554670685e811a15720d46cc4a2d/settings.py#L192

In this case, it appears that making SHA1 the default hasher wasn't accidental: https://github.com/dimagi/commcare-hq/commit/afa8f603bf1d2f3c335aba6ed8a16d46a2740f8b. It's unknown whether adding a system check would cause this project to make a change or if there's an ongoing reason that they're using that hasher (in which case a warning would only be an annoyance to suppress with SILENCED_SYSTEM_CHECKS).

All things considered, I agree with Mariusz that this is probably not a big problem in the Django ecosystem that justifies adding more code.