#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 |
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 by , 12 years ago
comment:2 by , 12 years ago
Has patch: | set |
---|
comment:3 by , 12 years ago
Triage Stage: | Unreviewed → 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 by , 12 years ago
Keywords: | sprint2013 added |
---|---|
Owner: | changed from | to
Status: | new → 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 by , 12 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 , 12 years ago
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 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:8 by , 12 years ago
(Aymeric is correct, I didn't intend to suggest a setting, just that we could document the subclassing approach.)
I think this is fixed in a pull request now: https://github.com/django/django/pull/703