Leakage usernames (timing attack) from password reset form

Problem/Motivation

I have reported this bug to the security team yesterday and they made clear they don't consider it a security issue due to the username enumeration policy of Drupal. I believe that's a matter of some debate. I will post the issue here (as suggested), because of the reason the finding will not be forgotten when the view on this topic changes in the future.

I found that there is a noticeable difference (~ 1.5 second) between requesting a password reset for an existing account and a non-existent one. This difference makes it possible to find out whether an account exists or not (timing attack).

The noticeable difference in response timing is due to Drupal sending the mail if the account exists (which takes approximately a second) and just returning the response when an account does not exist (approximately 50 ms).

Example of response times for three consecutive requests:

Proposed resolution

To prevent timing attacks, the following solutions could be considered:

• Change the execution order so that when a new password is requested a response is immediately returned to the user and the mail is sent afterwards.
• Another way to prevent a timing attack is to provide the password reset function a fake user so the whole process is performed on a non existing user. This will take the same amount of time and will therefore prevent a timing attack.
• Alternatively, have the application respond with the same general message for the password reset request, whether the entered mail address is valid or not. Send a mail to the entered e-mail address in both cases. In the case the user is unknown in the database simply let the message in the mail contain something like "A password reset has been requested for your account but according to our information there is no account registered with your address.".

Steps to reproduce

• Install the Drupal product with the versions listed above and configure an external mail provider.
• Request a new password for an existing user and repeat this request in a proxy tool like BurpSuite. This tool provides the response times for repeated requests.
• Perform the same request for a non-existent username and notice the difference.

Steps to reproduce

The following modules/versions have been tested:

• Drupal (9.4.8) and the SMTP Authentication Support (8.x-1.1) module was used. However, I saw the same issue arise when using Swiftmailer (so probably, the bug is located at Drupal Core).