#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.

-- 
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 on the web visit 
https://groups.google.com/d/msgid/django-updates/01070191d6041e3e-0cc84d14-4b62-4278-9e51-d9316b1490cc-000000%40eu-central-1.amazonses.com.

Reply via email to