Opened 12 months ago

Closed 7 months ago

#28718 closed Bug (fixed)

Password reset shouldn't depend on the current password being hashed with a supported hasher

Reported by: Josh Harwood Owned by: Tim Graham
Component: contrib.auth Version: 1.11
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Currently the built in django password reset system requires that you have an active account and that your password can be compared to by an enabled hasher.

I think that this is in error, as you are about to reset the password to something new (hence resetting it) and the standard process of password resetting requires an email confirmation. I can see no way in which this is able to be abused by a malicious 3rd party. If I'm mistaken here then feel free to correct me.

I propose that the system is changed to just require that the user is active and that their password is not marked disabled as per the UNUSABLE_PASSWORD_PREFIX.

Change History (10)

comment:1 Changed 12 months ago by Tim Graham

Type: BugCleanup/optimization

Where's that restriction implemented?

comment:2 in reply to:  1 Changed 12 months ago by Josh Harwood

Replying to Tim Graham:

Where's that restriction implemented?

This line with "has_usable_password": https://github.com/django/django/blob/master/django/contrib/auth/forms.py#L264

comment:3 Changed 12 months ago by Tim Graham

Summary: Resetting your password shouldn't depend on your current password being hashed with a supported hasherPassword reset shouldn't depend on the current password being hashed with a supported hasher
Triage Stage: UnreviewedAccepted
Type: Cleanup/optimizationBug

It looks like this is a regression in aeb1389442d0f9669edf6660b747fd10693b63a7. The change in django/contrib/auth/forms.py line 234 added the undesired check that the password uses a valid hasher.

comment:4 Changed 12 months ago by Levi Payne

Owner: changed from nobody to Levi Payne
Status: newassigned

comment:5 Changed 12 months ago by Levi Payne

Has patch: set

comment:6 Changed 12 months ago by Levi Payne

Needs tests: set
Patch needs improvement: set

Not going to be able to finish this. Just needs unit tests. See pull request for more details.

comment:7 Changed 12 months ago by Tim Graham

Owner: changed from Levi Payne to Tim Graham

comment:8 Changed 7 months ago by Tim Graham

Needs tests: unset
Patch needs improvement: unset

I think the change to has_usable_password() in 703c266682be39f7153498ad0d8031231f12ee79 was unintentional and that adding a User.has_disabled_password() method as originally proposed here will only add more confusion. I've proposed an alternate PR.

comment:9 Changed 7 months ago by Tim Graham <timograham@…>

In 43348e4a:

Reverted "[2.0.x] Expanded docs for AbstractBaseUser.has_usable_password()."

This reverts commit c2962d8147380b00bb965c0d42b7e05ca4596868. After discussion
in refs #28718, the decision is to treat the reverted statements as bugs.

comment:10 Changed 7 months ago by Tim Graham <timograham@…>

Resolution: fixed
Status: assignedclosed

In a4f0e9ae:

Fixed #28718 -- Allowed user to request a password reset if their password doesn't use an enabled hasher.

Regression in aeb1389442d0f9669edf6660b747fd10693b63a7.
Reverted changes to is_password_usable() from
703c266682be39f7153498ad0d8031231f12ee79 and documentation changes from
92f48680dbd2e02f2b33f6ad0e35b7d337889fb2.

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