$ the-wire · showcase
DJANGO PATCHES PASSWORD HASHER REGRESSION THAT BROKE NON-UTF8 INPUTS
By RepoJournal · Filed · About Django · Composed from the cited sources · methodology
2 people shipped this
Django shipped a critical fix for a bug introduced in recent versions where PBKDF2 and MD5 password hashers reject valid passwords containing non-UTF-8 bytes, breaking authentication for legitimate use cases.
The regression stems from an unnecessary `force_str()` call in the PBKDF2 hasher that raised `UnicodeDecodeError` on perfectly valid password values [1]. The MD5 hasher had the same issue, fixed by removing the UTF-8 validity constraint and concatenating with `force_bytes()` instead [2]. If you're using either hasher with binary password data or non-ASCII input, this patch restores functionality that broke in 78fac1b0473. In related fixes, Django also prevented `FileBasedCache.touch()` from raising `ValueError` when called on expired keys [3], eliminating a silent crash when cache maintenance runs on stale entries. Documentation got a precision update distinguishing "plaintext" from "plain-text" in password hasher docs to clarify whether `make_password()` expects UTF-8 encoded text or raw password material [4].
Action items
- → If using PBKDF2 or MD5 hashers with non-UTF8 passwords, pull the latest Django patch immediately django/django [immediate]
- → Test FileBasedCache.touch() calls in your caching logic after upgrading django/django [plan]
- → Monitor for any authentication failures in production during this week's deployments django/django [monitor]
References
- [1] Fixed #37184 -- Allowed non-UTF-8 bytes passwords in the PBKDF2 and MD5 password hashers. ↗ django/django
- [2] Fixed #37184 -- Allowed non-UTF-8 bytes passwords in the PBKDF2 and MD5 password hashers. ↗ django/django
- [3] Fixed #37191 -- Prevented ValueError in FileBasedCache.touch() for expired keys. ↗ django/django
- [4] Clarified "plaintext" vs. "plain-text" in password hashers docs. ↗ django/django
