#37184: PBKDF2PasswordHasher enforces UTF-8 decodable requirement on passwords
provided as bytes
-------------------------------------+-------------------------------------
Reporter: Johannes Leuschner | Owner: Vishy
Type: Bug | Status: assigned
Component: contrib.auth | Version: 6.0
Severity: Release blocker | Resolution:
Keywords: PBKDF2 hasher | Triage Stage: Accepted
password bytes UTF-8 |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Jacob Walls):
* cc: Sarah Boyce, Roelzkie (added)
* severity: Normal => Release blocker
* stage: Unreviewed => Accepted
* summary: PBKDF2PasswordHasher no longer accepts password of type bytes
=>
PBKDF2PasswordHasher enforces UTF-8 decodable requirement on passwords
provided as bytes
Comment:
Auth tests pass when I comment out the `password = force_str(password)`
line (and would be hash-preserving, given what's pointed out above about
the conversion back to bytes in the hasher). It looks like this was not
discussed in review, so it appears unintentional. (It might have been
added for parallelism with `force_str(salt)`, but that's not a real
parallel -- the salt gets string-interpolated, but the password doesn't.)
I agree we shouldn't impose a constraint on the universe of valid secure
passwords at the hasher level. Forms and validators and management
commands may expect strings only, but that's separate.
scrypt/argon2/bcrypt appear to accept these bytes, so we have a
consistency issue (consistency was the rationale for accepting #36226).
MD5 is a different beast entirely because the password and salt get
concatenated.
If we wanted some sort of canonicalization check, I don't think we'd put
it in the hasher.
--
Ticket URL: <
https://code.djangoproject.com/ticket/37184#comment:3>
Django <
https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.