Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#19758 closed Bug (fixed)

Password reset form should not leak information

Reported by: anonymous Owned by: Horst Gutmann
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 4 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 4 years ago by fhahn

Has patch: set

comment:3 Changed 4 years ago by Carl Meyer

Triage Stage: UnreviewedAccepted

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 4 years ago by Horst Gutmann

Keywords: sprint2013 added
Owner: changed from nobody to Horst Gutmann
Status: newassigned

@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 4 years ago by Aymeric Augustin

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 4 years ago by Horst Gutmann

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 4 years ago by Aymeric Augustin <aymeric.augustin@…>

Resolution: fixed
Status: assignedclosed

In 2f4a4703e1931fadf5ed81387b26cf84caf5bef9:

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

comment:8 Changed 4 years ago by Carl Meyer

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

comment:9 Changed 3 years 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 3 years 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