Opened 2 hours ago
Last modified 113 minutes ago
#37375 new Bug
`ScryptPasswordHasher` cannot verify hashes with non-default derived key lengths — at Version 1
| Reported by: | Dominic Roy | Owned by: | |
|---|---|---|---|
| Component: | contrib.auth | Version: | 5.2 |
| Severity: | Normal | Keywords: | scrypt password hasher dklen |
| Cc: | Dominic Roy | Triage Stage: | Unreviewed |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description (last modified by )
ScryptPasswordHasher currently hardcodes dklen=64 when calling
hashlib.scrypt().
As a result, Django cannot verify otherwise valid scrypt password hashes
generated by another implementation when that implementation uses a larger
derived key length.
This came up while working on password hash compatibility in authentik
(https://goauthentik.io), where imported scrypt hashes may come from systems
using different dklen values.
Django should probably keep 64 bytes as the minimum accepted derived key
length rather than accepting arbitrary shorter hashes. However, hashes with a
larger dklen, for example 128 bytes, currently fail verification because
verify() always regenerates a 64-byte result.
The derived key length can be recovered from the length of the Base64-decoded
digest. verify() could use that value when it is at least 64, while Django
continues generating new hashes with dklen=64.
If appropriate under Django's backport policy, it would also be useful to
include this in Django 5.2 LTS.
I'm happy to submit a patch with tests if this approach is accepted.