Opened 3 years ago

Closed 3 years ago

Last modified 23 months ago

#19758 closed Bug (fixed)

Password reset form should not leak information

Reported by: anonymous Owned by: zerok
Component: contrib.auth Version: master
Severity: Normal Keywords: sprint2013
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description

The provided password reset form leaks information about enrolled users by providing information as to whether an email is enrolled. This is obviously untenable for any site with even moderate confidentiality requirements.

Correct behavior is to display the same result regardless of whether an email is found in the database.

Change History (10)

comment:1 Changed 3 years ago by anonymous

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

I think this is fixed in a pull request now: https://github.com/django/django/pull/703

comment:2 Changed 3 years ago by fhahn

  • Has patch set

comment:3 Changed 3 years ago by carljm

  • Triage Stage changed from Unreviewed to Accepted

I know this has been debated in the past, but I agree that the default behavior should be safe with respect to both security and confidentiality requirements. If some people want a "friendlier" password reset and don't care about these requirements, we can document an easy path to providing different responses depending whether the email address is enrolled.

comment:4 Changed 3 years ago by zerok

  • Keywords sprint2013 added
  • Owner changed from nobody to zerok
  • Status changed from new to assigned

@carljm so you basically want to have the default behaviour to be the "secure" approach and perhaps offer a setting (either globally or on a per-form level) to switch to a version that exposes the existence of a user's email?

comment:5 Changed 3 years ago by aaugustin

We don't need a setting for this. Django should follow the best practice of not leaking information.

Developers can adjust this (depending on their requirements) through subclassing. This could be documented.

comment:6 Changed 3 years ago by zerok

https://github.com/django/django/pull/754 contains a new version of the pull request. It is no based on the one by Kenn Knowles and goes a bit further by also updating the documentation and templates.

comment:7 Changed 3 years ago by Aymeric Augustin <aymeric.augustin@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

In 2f4a4703e1931fadf5ed81387b26cf84caf5bef9:

Fixed #19758 -- Avoided leaking email existence through the password reset form.

comment:8 Changed 3 years ago by carljm

(Aymeric is correct, I didn't intend to suggest a setting, just that we could document the subclassing approach.)

comment:9 Changed 23 months ago by Claude Paroz <claude@…>

In 5f52590368063fc8284e23be492d83ba751f66bf:

Fixed #21291 -- Ensured inactive users cannot reset their passwords

Thanks kz26 for the report and the suggested fix. Refs #19758.

comment:10 Changed 23 months ago by Claude Paroz <claude@…>

In 0c850e28858016b5890ae83a6ec6880614b306a2:

[1.6.x] Fixed #21291 -- Ensured inactive users cannot reset their passwords

Thanks kz26 for the report and the suggested fix. Refs #19758.

Backport of 5f5259036 from master.

Note: See TracTickets for help on using tickets.
Back to Top