Problem/Motivation
This is the backport of #1521996: Password reset form reveals whether an email or username is in use where a patch has been committed to drupal 9 and a patch for drupal 7 exists and needs to be re-rolled.
Excerpt from original issue summary:
The actual password reset mechanism exposes a user enumeration security vulnerability defined as Testing for User Enumeration and Guessable User Account (OWASP-AT-002) by OWASP - Open Web Application Security Project.
Along with the security aspect comes also the privacy side.
A separate issue #2346389: Prevent registered e-mail address enumeration via user registration form is for new registrations and creating accounts and there is currently little development on that issue.
Steps to reproduce
See original issue summary.
Proposed resolution
A patch for drupal 7 from the previous issue needs to be re-rolled, reviewed, and tested.
From original issue summary:
- Remove message from validateForm that display user name and/or email.
- Change message in submitForm to display user input so they can check for typos but status that if it is valid an email is sent.
Message agreed upon.
Patch #257 - "If %identifier is a valid account, an email will be sent with instructions to reset your password."
Remaining tasks
Continuing from original issue summary:
- Debate backports.
- Re-roll as appropriate.
- Decide on a follow-up so that the password recovery message is configurable from the UI. See #1521996-237: Password reset form reveals whether an email or username is in use
User interface changes
Same message regardless the user exists, is active or blocked.
This also decreases usability for users since they might be resetting their password with the wrong email address and then wonder why they never get an email. Right now you immediately know that you typed in a wrong email address.
To avoid https://owasp.org/www-community/attacks/Content_Spoofing and to partially mitigate the UX regression that there's no feedback if you're typing something invalid, the form now at least validates that the input is either a valid username or a valid email address. If the input is neither, you get a validation error message about it (since that's not a privacy violation).
Decreased usability vs. better privacy is probably a tradeoff we accept.
API changes
2 new injected services are needed in the UserPasswordForm constructor. @see https://www.drupal.org/node/3189310
Data model changes
None.
Release notes snippet
Password reset form no longer indicates whether the provided username or email address is in the database.