Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#19758 closed Bug (fixed)

Password reset form should not leak information

Reported by: anonymous Owned by: Horst Gutmann
Component: contrib.auth Version: dev
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


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 by anonymous, 11 years ago

I think this is fixed in a pull request now:

comment:2 by fhahn, 11 years ago

Has patch: set

comment:3 by Carl Meyer, 11 years ago

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

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 by Aymeric Augustin, 11 years ago

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 by Horst Gutmann, 11 years ago 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 by Aymeric Augustin <aymeric.augustin@…>, 11 years ago

Resolution: fixed
Status: assignedclosed

In 2f4a4703e1931fadf5ed81387b26cf84caf5bef9:

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

comment:8 by Carl Meyer, 11 years ago

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

comment:9 by Claude Paroz <claude@…>, 11 years ago

In 5f52590368063fc8284e23be492d83ba751f66bf:

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

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

comment:10 by Claude Paroz <claude@…>, 11 years ago

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