Opened 2 years ago

Closed 2 years ago

#21660 closed Uncategorized (invalid)

Password reset form return a successful answer when the email doesn't exist in the database

Reported by: anonymous Owned by: nobody
Component: contrib.auth Version: 1.6
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no



The django.contrib password_reset view doesn't come with any machnism to handle the situation where the email doesn't exist in the database, it just send to a page telling that an email has been sent to the address.

For reference, password_reset the email sending is done in the save of the form line 162. The query to grab the user (or list of user) in the form is here

Also, the behavior to get the user(s) is strange, it can result of sending several time the same email to the same mail address, I really don't get the loop part, is it because of the test on user.has_usable_password()? If yes, then why there isn't a break at the end of the loop to prevent multiple sent emails. Or is it because of the case insensitive query?

Kinds regards,

Change History (3)

comment:1 Changed 2 years ago by cortex@…

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

comment:2 Changed 2 years ago by aaugustin

Regarding the first point, it's a security requirement, to avoid leaking the existence of an email in the database to a casual onlooker. (A serious attacker may be able to extract that information with a timing attack.)

comment:3 Changed 2 years ago by russellm

  • Resolution set to invalid
  • Status changed from new to closed

Regarding the second point - it's because email isn't a unique field on the default User model. As a result, a user could have multiple accounts. The reset email itself should (ideally) contain the username as well to provide a disambiguation.

Given that both points raised by this ticket seem to be a misunderstanding, closing the ticket invalid. There might be an argument to improve the documentation around these points; #21661 should cover that.

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