#35730: Enhance password reset security by encrypting 'uid' parameter instead of
base64-encoding to prevent possible user count leakage
--------------------------------------+------------------------------------
Reporter: Remy | Owner: Remy
Type: Cleanup/optimization | Status: assigned
Component: contrib.auth | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Changes (by Simon Charette):
* cc: Carlton Gibson, Natalia Bidart, Simon Charette (added)
Comment:
Hello Remy, thank you for your patch submission.
Over the past week the security team had the chance to review it and after
some deliberation we came to the conclusion that we might want to change
our stance and consider this ticket as ''won't fix'' for the following
reasons
- As discussed previously this only addresses one way that user ids can be
enumerated and the only true way to prevent this problem from happening is
to switch to non-enumerable user-facing identifiers (e.g. UUIDs) which
Django supports.
- While your salted XOR implementation appears to be correct (thanks for
trying it out btw) we don't believe that the nature of this problem
(enumeration) warrants the complexity it introduces.
- We considered that we might want to repurpose to this ticket to make it
easier for interested user to rollout their own implementation of `User ->
uid -> User` but we feared that it might be to niche and cause more harm
than good if it was to be poorly overridden.
- Lastly we discussed that instead of sending along the `UserModel.pk` in
the `uid` could send the `UserModel.USERNAME_FIELD` attribute which is
also unique and due to the inclusion of the `pk` in the hash would be
immediately invalidated on a username swap. After all `uid` is user
controlled so any field that allows for unique retrieval of a user should
(safely work)?
I'd like to personally apologize for sending you down the rabbit hole and
keeping you waiting for so long for feedback, we were truly unsure how to
proceed here and needed to reach a consensus to avoid even more confusion.
With all that said we'd like to give you the opportunity to chime in
before we move forward with what we believe should have been the initial
response to your report.
--
Ticket URL: <https://code.djangoproject.com/ticket/35730#comment:13>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/01070192cf869794-9b83060c-a248-43e4-a6d3-29732a62060a-000000%40eu-central-1.amazonses.com.
