#36901: Centralize mitigations against timing attacks
-------------------------------------+-------------------------------------
Reporter: Jacob Walls | Type:
| Cleanup/optimization
Status: new | Component:
| contrib.auth
Version: dev | Severity: Normal
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
The patch for CVE 2025-13473 (3eb814e02a4c336866d4189fa0c24fd1875863ed)
runs the default password hasher once in
`django.contrib.auth.handlers.modwsgi` just like `ModelBackend` has done
since #20760.
A refactor in exposing this functionality in a central place that the
`mod_wsgi` auth handler could just call is worth exploring.
The Security Team decided against attempting that refactoring in a patch
release.
Additional findings:
- `aauthenticate()` still does manual extra hashing
- `verify_password()` still does manual extra hashing
- in the `mod_wsgi` auth handler, handling of custom user models lacking
the "is_active" attribute should be clarified. It currently raises
`AttributeError`, but to align with `ModelBackend`, we could change the
semantic.
So, the acceptance requirements for this ticket would be something like:
- no behavior changes
- except for possibly the `AttributeError` edge case discussed above, if
documented appropriately
- reduce the number of calls to `set_password("")`
- avoid coupling the `modwsgi` handler to `ModelBackend`
Another outcome would be a bit of work showing that this has pitfalls or
isn't worth it.
--
Ticket URL: <
https://code.djangoproject.com/ticket/36901>
Django <
https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.