#33691: Deprecate CryptPasswordHasher.
-------------------------------------+-------------------------------------
Reporter: Mariusz Felisiak | Owner: Mariusz
Type: | Felisiak
Cleanup/optimization | Status: closed
Component: contrib.auth | Version: 4.0
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Nick Pope):
Replying to [comment:3 Mariusz Felisiak]:
> Replying to [comment:2 Florian Apolloner]:
> > ACK, while we are on it I wonder if we should deprecate the unsalted &
sha/md5 hashers as well. It is time to face reality, if you haven't
upgraded Django by now and are still on one of those old algorithms your
installation is probably 10 years or older?
>
> `MD5PasswordHasher` is still a nice hook for faster testing :)
Like Florian, I also think that now is the time to get rid of the
following hashers:
- `MD5PasswordHasher`
- `SHA1PasswordHasher`
- `UnsaltedMD5PasswordHasher`
- `UnsaltedSHA1PasswordHasher`
It is long past time that these were gone, and they were removed from the
default `PASSWORD_HASHERS` setting in Django 1.10 along with
`CryptPasswordHasher`. In addition, they will not be fully removed until
December 2023, so that gives Django 4.1 and 4.2 to move of these, and 4.2,
being an LTS, gives plenty of time beyond that.
Yes, it'd be nice to keep something fast around for testing purposes and
we've been recommending `MD5PasswordHasher` up to now, but I don't think
that should prevent removal of the other three at the very least...
However, I propose that we add an explicit new `TestPasswordHasher` that
has something in place to scream about not using it outside of local
development environments and continuous integration pipelines for the
purpose of speeding up testing. Maybe this could be achieved with the
check framework (disabled when using testing tools). Or disabled when
Django is executed via normal ASGI/WSGI stuff as would be done in
production, but not when running tests. Or that `TestPasswordHasher` will
only work when it is the only hasher.
Another question would be whether we make it still use MD5 as the
algorithm, or whether, now that we're making it explicitly for testing, we
make it even faster by making it totally insecure? (Although this would
maybe be a step to far in case of people still ignoring all the
warnings...)
I started messing around very roughly with this idea on the following
branch, but I don't really have all that much time to follow it up right
now. It needs thought about how we'd flag up and/or block use of
`TestPasswordHasher` in the wrong places.
https://github.com/ngnpope/django/tree/test-password-hasher
--
Ticket URL: <https://code.djangoproject.com/ticket/33691#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/01070180b9e052d5-cab9cd92-93b6-4dc9-9118-13a7a09ac01b-000000%40eu-central-1.amazonses.com.
