@dom_walden What is the content of the "Action throttled" message?

In T249730#6043861, @ifried wrote:

@dom_walden What is the content of the "Action throttled" message?

"As an anti-abuse measure, you are limited from performing this action too many times in a short space of time, and you have exceeded this limit. Please try again in a few minutes."

@Reedy We are thinking of resolving this issue by redirecting all users to the same informational display after they submit information (whether or not there is a 'mailpassword' limit issue). The page would display information about the mail password limit. Here is a current screenshot example of the page (without the new text that we plan to add).

The other action is to show the action throttled message to all users. Does either solution work/do you have a preference?

@Prtksxna Do you recommend we show the action throttled message to all users (which is probably easier, since no additional translations would be required) or redirect users to the next screen (since follows the general principle that all users be redirected to next screen after submitting info)? And, if we do redirect users to the next screen, we'll need to think of new text. Here is an idea: "Furthermore, you can only request a limited number of password resets within a short period of time. If you didn't receive an email, wait a few minutes and then try again." What do you think of the proposed text? Thanks!

@dom_walden I'm unable to reproduce the issue when I test. I keep on seeing the informational screen in all cases, whether the account has Enhanced Password Reset enabled. Any tips on how to reproduce this? Thanks!

In T249730#6047602, @ifried wrote:

@dom_walden I'm unable to reproduce the issue when I test. I keep on seeing the informational screen in all cases, whether the account has Enhanced Password Reset enabled. Any tips on how to reproduce this? Thanks!

@ifried Try it 5 times and see if you are able to get the throttle message. It's a setting that needs to be reached per wiki.

@dom_walden I tried over 5 times... maybe I'm missing something.

@dom_walden: Update -- reproduced it! The issue was probably that I was logged in. I was originally testing directly via the URL link for Special:PasswordReset, while logged in. In that case, when I tried repeated attempts, it was the same behavior for any username (whether or not PRU was enabled). However, when I logged out, I saw the difference. Thanks.

In T249730#6047658, @ifried wrote:

@dom_walden: Update -- reproduced it! The issue was probably that I was logged in. I was originally testing directly via the URL link for Special:PasswordReset, while logged in. In that case, when I tried repeated attempts, it was the same behavior for any username (whether or not PRU was enabled). However, when I logged out, I saw the difference. Thanks.

Oh, interesting. If the user you were logged in as were an admin, it might not be affected by throttles.

In T249730#6045262, @ifried wrote:

@Prtksxna Do you recommend we show the action throttled message to all users (which is probably easier, since no additional translations would be required) or redirect users to the next screen (since follows the general principle that all users be redirected to next screen after submitting info)? And, if we do redirect users to the next screen, we'll need to think of new text. Here is an idea: "Furthermore, you can only request a limited number of password resets within a short period of time. If you didn't receive an email, wait a few minutes and then try again." What do you think of the proposed text? Thanks!

Yep, I think it makes sense to just show it to all users. The text you've drafted looks good. If we're able to find out, and if its consistent across wikis we could update "limited number of password resets" and "a short period of time" to actual figures. This might help good faith users out if they're confused.

@sbassett & @Reedy Are you okay with how we are planning to fix this issue (see acceptance criteria above)? We plan to have one unified message displayed to all users, which lets them know about various reasons why a password reset email may not have been sent. Thanks!

In T249730#6056141, @ifried wrote:

We plan to have one unified message displayed to all users, which lets them know about various reasons why a password reset email may not have been sent.

Sounds good to me. Feel free to add @Reedy and I as reviewers when the patch is ready on-task or in gerrit.

Thank you so much, @sbassett! I'll let the team know.

The specifications in this ticket have been implemented. Please note that there was a loophole in the code. The logic that checks for the $wgRateLimit has been moved above the Enhanced Password Reset check so it is possible to keep the Action throttle message if we wanted to. By moving the mailpasswordlogic, we avoid the possibility of disclosing any private information if we decided to keep and trigger the Action throttle message. The users would see the throttle message whether they have enabled PRU or not.

@HMonroy @ifried Ugh, I've found another set of conditions where this also happens:

If I submit the Special:PasswordReset form with a username which has PRU enabled and an invalid email (e.g. "email|address"), the form returns the message "Invalid email address".

For a username with PRU disabled, the form submits and returns the usual message ("If the information submitted is valid...").

Same or separate ticket?

You might have to programmatically submit the form (e.g. via curl), as most/all browsers implement their own form of email validation which usual prevents invalid email addresses being submitted.

For example, curl -X 'POST' 'http://dev.wiki.local.wmftest.net:8080/w/index.php?title=Special:PasswordReset' --data "wpUsername=Eve&wpEmail=foo|bar&title=Special%3APasswordReset&redirectparams="

@dom_walden Thanks for catching this!

@HMonroy Can this be fixed in this ticket, or no? We want the behavior to be that all users are redirected to the next informational screen. Thanks!

@dom_walden Thanks! I see where the problem is.

@ifried The user gets the "Invalid email address" error when they submit emails like: "foo", "foo@wiki", "wiki.com". I just want to verify that we are eliminating the "Invalid email address" altogether and showing the general message instead.

I'll create a followup patch, no need to create a separate ticket.

@HMonroy Yes, let's still direct users to the next screen. They will see the information that they input in the informational screen, so they should be able to ascertain if the email address is correct. I'll also update the documentation to cover cases associated with incomplete email addresses.

When throttled, the user no longer sees some (perhaps all?) of the validation messages they would see when not throttled. These include:

• When entering an invalid username (e.g. "user|name")

Not throttled:

• When entering a blank username and email

Not throttled:

I don't know of any others, but there might be.

@ifried Is this ok?

Thanks for catching this, @dom_walden! Yes, I think this is okay. Here's why:

• This merely exposes throttling (which was previously exposed).
• We are not exposing any information related to user accounts or preferences.

For these reasons, I don't think that this is a blocker for us to enable the 'Enhanced Password Reset' on Wikipedia . In addition, I don't think this needs to be immediately changed (though it can be in the future). If the security team wishes to further standardize the process, they can certainly do so. But I think we should be okay with the current state of the work, which has improved security overall. Thanks!

Note: This is now on production. I have tested it on production, and it looks good. But I'll wait for Dom to officially move this to product sign-off before I close it. Thanks!

@ifried - We should also make this task public once it's completely resolved. I suppose this would've been iffy to hold for the next security release (T248535), since it's likely not a major issue, but that doesn't really matter since the patch sets for master are public:

• https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/589815/
• https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/589129/

We'll probably want to see about backporting those to supported release branches, if feasible.

I can no longer reproduce the bugs in the description and T249730#6062487.

We no longer appear to show the "Action throttled" in any circumstances (that I have seen so far).

Similarly to T246844#5991422, I submitted Special:PasswordReset with a combination of user + email on https://wikidata.beta.wmflabs.org (which has PRU).

Details below. The only issues I can see are those already described in T249730#6089025.

Setup:

Results:

#0 = "If the information submitted is valid, a password reset email will be sent..." with neither Username nor Email displayed (as shown in T249730#6089025).
#1 = "If the information submitted is valid, a password reset email will be sent..." with Username displayed.
#2 = "If the information submitted is valid, a password reset email will be sent..." with Email displayed.
#3 = "If the information submitted is valid, a password reset email will be sent..." with Username and Email displayed.
userPIPEname = "user|name", but I cannot put pipes into tables in Phab

Thank you, @dom_walden!

@HMonroy: This ticket has now been moved to product sign-off. So, we can proceed with enabling Enhanced Password Reset on Wikipedia (as per T245791) on Wednesday. Thanks!

@ifried @dom_walden @HMonroy - I'd like to make this task public especially since the code changes were done publicly in gerrit anyways. I'm not seeing any PII or overly-sensitive data on the task unless, @dom_walden, you're not comfortable with some of the test data you've posted. Let me know, thanks.

In T249730#6125337, @sbassett wrote:

@ifried @dom_walden @HMonroy - I'd like to make this task public especially since the code changes were done publicly in gerrit anyways. I'm not seeing any PII or overly-sensitive data on the task unless, @dom_walden, you're not comfortable with some of the test data you've posted. Let me know, thanks.

I am fine with my data being public.

Change 597829 abandoned by SBassett:
[SECURITY] Password Reset Updates

Reason:
DatabaseBlock only available from 1.34 . Will attempt backport to that branch.

https://gerrit.wikimedia.org/r/597829

Change 601437 had a related patch set uploaded (by SBassett; owner: HMonroy):
[mediawiki/core@REL1_34] [SECURITY] Password Reset Updates

https://gerrit.wikimedia.org/r/601437

Change 601437 merged by jenkins-bot:
[mediawiki/core@REL1_34] [SECURITY] Password Reset Updates

https://gerrit.wikimedia.org/r/601437