id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
37375	`ScryptPasswordHasher` cannot verify hashes with non-default derived key lengths	Dominic Roy		"`ScryptPasswordHasher` currently hardcodes `dklen=64` when calling
`hashlib.scrypt()`.

This means Django cannot verify an otherwise valid scrypt password hash
generated by another implementation if that implementation used a different
derived key length.

This came up while working on password hash compatibility in authentik (https://goauthentik.io), where
we need to be able to verify scrypt hashes imported from other systems.

For example, these two hashes use the same password, salt, N, r, and p values,
but different derived key lengths:

{{{
scrypt$1024$salt$8$5$Xo0CV8Rk/C+B2LSvQ/MgyKJmMtW6yik2PCmVEtsZyMu01U+2KSQrCJnGfrVo4+hqUkv7Oq+AyCG9eaNdpJSn5w==
scrypt$1024$salt$8$5$Xo0CV8Rk/C+B2LSvQ/MgyKJmMtW6yik2PCmVEtsZyMu01U+2KSQrCJnGfrVo4+hqUkv7Oq+AyCE=
}}}

The first uses `dklen=64` and verifies with Django. The second uses
`dklen=56` and does not.

Django's encoded scrypt format does not contain an explicit `dklen` field,
but the value can be recovered from the length of the Base64-decoded digest.
`verify()` could as a result derive the original key length from the stored
hash and pass it to `hashlib.scrypt()`.

Django could continue generating new hashes with `dklen=64`. Hashes using a
different derived key length could also be considered for upgrade by
`must_update()`, so they are re-encoded using Django's preferred parameters
after a successful login.

This would make importing existing scrypt password hashes from other
implementations possible without requiring otherwise valid passwords to be
reset.

If this qualifies for backporting, it would also be useful to have the fix in
Django 5.2 LTS.

I'm happy to submit a patch if this approach is accepted!"	Bug	new	contrib.auth	5.2	Normal		scrypt password hasher dklen	Dominic Roy	Unreviewed	0	0	0	0	0	0