Re: [Django] #35730: Enhance password reset security by encrypting 'uid' parameter instead of base64-encoding to prevent possible user count leakage (was: Enhance password reset security by signing 'uid' parameter instead of base64-encoding to prevent possible user count leakage)

[Django]

#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: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Changes (by Remy):

* summary:
Enhance password reset security by signing 'uid' parameter instead of
base64-encoding to prevent possible user count leakage
=>
Enhance password reset security by encrypting 'uid' parameter instead
of base64-encoding to prevent possible user count leakage


Old description:

> When using Django’s default view for requesting a password reset,
> `PasswordResetView`, the `PasswordResetForm`’s save() method sends an
> email containing a `uid` parameter generated using
> `urlsafe_base64_encode(force_bytes(user.pk))`.
>
> This results in the user’s email inbox containing a password reset link
> that indirectly reveals the user’s primary key (`user.pk`), which exposes
> information about how many users exist on any Django site that uses this
> default view.
>
> Surely, organizations that design their entities with non-enumerable
> public identifiers (such as by using a `UUIDField` for the primary key)
> would not be affected by this, however as the issue is also addressed by
> other means, such as a secondary public identifier, or simply a careful
> app design, I would still think that many Django site owners who prefer
> to keep this information private are likely unaware that it’s being
> exposed through this native mechanism.
>
> To prevent the leakage of the `user.pk` value by default, I replaced the
> base64 encoding with the signing of the `user.pk` value (PR
> https://github.com/django/django/pull/18539).

New description:

When using Django’s default view for requesting a password reset,
`PasswordResetView`, the `PasswordResetForm`’s save() method sends an
email containing a `uid` parameter generated using
`urlsafe_base64_encode(force_bytes(user.pk))`.

This results in the user’s email inbox containing a password reset link
that indirectly reveals the user’s primary key (`user.pk`), which exposes
information about how many users exist on any Django site that uses this
default view.

Surely, organizations that design their entities with non-enumerable
public identifiers (such as by using a `UUIDField` for the primary key)
would not be affected by this, however as the issue is also addressed by
other means, such as a secondary public identifier, or simply a careful
app design, I would still think that many Django site owners who prefer to
keep this information private are likely unaware that it’s being exposed
through this native mechanism.

To prevent the leakage of the `user.pk` value by default, I replaced the
base64 encoding with the ~~signing~~ encrypting of the `user.pk` value (PR
https://github.com/django/django/pull/18539).

--
--
Ticket URL: <https://code.djangoproject.com/ticket/35730#comment:9>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.