Page MenuHomePhabricator

Anon-only range block doesn't allow password resets
Open, Needs TriagePublic

Description

Today, the we had a user come to irc asking for support since he couldn't log in with his account, as he had forgotten his password and his IP matched an anon-only range block.

Looking at the code of canChangePassword(), added in eb09d10fa6dbf03a723d3ba5d9e794414f288b76, seems the intention was to avoid when the user themself (that would be an IP) was blocked, per the comment «Maybe the user is blocked».

Removing the ability to reset your password (the one which would allow you to edit!) due to an anon-only range block seems wrong. Sending password resets is considered quite inoffensive, and a range block is probably not the right tool to prevent that anyway, whereas not being able to enter to your account has a very noticeable effect.

OTOH we could keep the feature if it's the individual IP what is blocked (not sure about corporate proxies, though).

PD: As a sidenote, the blocked-mailpassword message was shown with an "Internal Error" page title: https://www.filepicker.io/api/file/O3SCr3TSTeOH6iAVjGz5

Event Timeline

Platonides raised the priority of this task from to Needs Triage.
Platonides updated the task description. (Show Details)

Change 326355 had a related patch set uploaded (by Brian Wolff):
Allow password resets from anon-only range blocks

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

So how will one prevent such users from trying bulk password resets for many accounts? By switching the range block to also affect registered users? It would be easier to be lenient with password resets from abused IP addresses if there was some rate limit on the IPs (T122164#2791389).

So how will one prevent such users from trying bulk password resets for many accounts? By switching the range block to also affect registered users? It would be easier to be lenient with password resets from abused IP addresses if there was some rate limit on the IPs (T122164#2791389).

$wgRateLimits['mailpassword']

Copying what I said on the gerrit change:

Some time ago checkusers and stewards went crazy when a prolific vandal started doing massive password resets from many IP addresses. And since the only activity that came from those ranges were those password resets, an anon-block only global or local rangeblock was enough to stop it. If this goes forward, there's again potential for abuse, unless there's a ratelimit of password resets an account can request, and such rate limit should be global (for all CentralAuth wikis). I'd prefer this not to be allowed. Thanks.

What about adding a new option on the block page to prevent password reset, that would be activated only in such scenarios?

What about adding a new option on the block page to prevent password reset, that would be activated only in such scenarios?

I'm not sure if that'd work. People will check it by default and the block page has already too many options. Maybe we can make that blocks with the flag 'account creation disabled' should have implicitly password reset revoked, but then if the only abusive activity comming from that IP or IP range is password resets, we'd be blocking legit users from creating an account.

Copying what I said on the gerrit change:

Some time ago checkusers and stewards went crazy when a prolific vandal started doing massive password resets from many IP addresses. And since the only activity that came from those ranges were those password resets, an anon-block only global or local rangeblock was enough to stop it. If this goes forward, there's again potential for abuse, unless there's a ratelimit of password resets an account can request, and such rate limit should be global (for all CentralAuth wikis). I'd prefer this not to be allowed. Thanks.

The current ratelimits are: Each account can only get 1 reset per 24 hours (That's not perwiki though), and each anon user can only send 5 resets per hour (global, but not for logged in users). What sort of rate limits do you think would be appropriate? (We should probably fix rate limits regardless of the block thing)

What sort of rate limits do you think would be appropriate? (We should probably fix rate limits regardless of the block thing)

I proposed to use the same limits, cf. https://gerrit.wikimedia.org/r/#/c/321334/ .

Xauroflaux subscribed.

This needs to be fixed. Period.

Ciencia_Al_Poder raised the priority of this task from High to Needs Triage.Apr 11 2017, 8:17 PM

This needs to be fixed. Period.

Are you going to write a patch to fix this yourself? if not, please do not mess with priorities. Report status and priority fields summarize and reflect reality and do not cause it. Read about the meaning of the Priority field values and, when in doubt, do not change them, but add a comment suggesting the change and convincing reasons for it.

Users global account is locked, and thus they are unable to log in here and comment on this.

I had this problem yesterday on en-wiki. If I hadn't also been logged in on my phone I would have had no way to ask for help. THe message when i was trying to reset my password was profoundly unhelpful. See this post on MediaWiki and my talk page on en-wiki

You should have been able to use Special:PasswordReset from your phone which was still logged in, in which case the soft nature of the block would have made it not apply. It's not clear whether you tried this; it worked for me on my local development wiki, although I can't guarantee there isn't something special about Wikipedia's configuration that would make it not work there.

IPBE on your account doesn't apply to things you try to do when you're not logged in to your account, of course. The block being "soft" also isn't relevant when you're not logged in to your account.

If I hadn't also been logged in on my phone I would have had no way to ask for help.

You could have used any appropriate mailing list or IRC channel to ask for help. For enwiki, WP:UTRS could likely also have helped. If you were already logged in to Phabricator, you could also have submitted a task about it here.

For the specific action of submitting Special:PasswordReset, you could have had anyone who wasn't affected by a block enter your username into Special:PasswordReset and submit the form for you. They needn't be an admin on-wiki, or even have an account.

If you have any Internet access that isn't affected by a block, you could also have used that to submit the form. Then, from your normal home or mobile Internet access, you could have logged in using the emailed temporary password.

THe message when i was trying to reset my password was profoundly unhelpful.

That message comes from the GlobalBlocking extension, globalblocking-blocked-nopassreset. I filed T202277: globalblocking-blocked-nopassreset lacks detail about the block for that issue.

Anomie. 1) I didn't want to log out from my phone - it is the same IP as my desktop and I didn't want to risk being locked out from there too.

2)"You could have used any appropriate mailing list or IRC channel to ask for help. For enwiki, WP:UTRS could likely also have helped. If you were already logged in to Phabricator, you could also have submitted a task about it here." - I don't know any mailing lists or IRC channels. I don't really know what IRC is at all. The message refusing me a password reset didn't tell me ay of this, so how was I supposed to know?

  1. I only started using phabricator today after someone linked to this thread from the thread on Wikimedia (which I ony started using yesterday because Swarm gave me the link to his thread).

Most people using Wikipedia won't have a clue about all this backroom stuff. We just get falsely accused of being globally blocked and offered no information whatsoever about how to sort it out.

Please don't assume that people will know things that nobody has ever told them and that they've never needed to find out.

Sorry about the poor formatting of my reply, I have never used Phabricator before and it's weird.

Anomie. 1) I didn't want to log out from my phone

Where did I suggest you do so?

Anomie, is it possible to request a password reset when logged in? I've only ever seen it offered when trying to log in and I've mis-typed or forgotten my password.

It is, simply visit Special:PasswordReset.

P.S. Don't confuse that with Special:ResetPassword. The fact that both of those exist and do different things is very confusing, and that the title for Special:PasswordReset is "Reset password" is even more so.

Anomie, well how was I meant to know that? Did anyone tell me? Have I ever, in twelve years of using Wikipedia ever come across that?

No, and no.

Telling people who point out a problem that they should have done things that are utterly obscure is not helpful.

What's the difference between Special:PasswordReset and Special:ResetPassword? Is that something else I'll be criticised for not knowing?

And that none of the Admins, including the person who set the global block, seemed to know anything about this suggests it is really obscure.

On the other hand, getting defensive when people do tell you things you didn't already know isn't very helpful either. I'm not trying to criticize you for not knowing things already, and I apologize for the fact that it's coming across that way.

The difference is that Special:PasswordReset is the password recovery thing we've been talking about, while Special:ResetPassword is an alias for Special:ChangePassword (i.e. changing your password when you're already logged in).

Next time try starting with "Sorry you had this problem, here are some suggestions in case it happens again", that way the person you are talking to might get the feeling that you are trying to help.

Perhaps it would help if people weren't allowed to set global IP blocks unless they knew all this stuff so they could help with the fallout from their actions. Clearly, as it stands, they don't. When they set such a block are they warned that it will prevent users resetting their passwords, and told how to help them when it does?

Users also get useless messages if they try to edit telling them to contact the blocker, which is impossible if blocked. I don't know if those messages are because of something here or on en-wiki.

Improving the frankly horrible message ("you have been globally blocked") that users get would also help.

If my phone hadn't been logged in I would have had to resort to emailing those admins whose addresses I have saved - on the off-chance that one of them might a) have been available, and b) have known something that the person who set the global block didn't know.

Change 326355 abandoned by Brian Wolff:
Allow password resets from anon-only range blocks

Reason:
Requires political agreement

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

I just had an anon user try to recover their account because their IP was blocked; they just wanted to log in and edit. Why do we restrict access to account recovery where we apply a block to an IP or range that requires an existing account to edit? This would be normal behavior in my mind. The user just wants to recover their account so they can log in and edit... And they can't because IP block...

This restriction should only apply if the IP or range is HARD BLOCKED (no account creation, no edits from existing accounts). Otherwise, with less-restrictive blocks, we should expect users to need to access that so they can edit....

What can we do to facilitate a discussion and decide that this should be changed, and to what level?

Isn't this what the "block sending e-mails" option is for?

Isn't this what the "block sending e-mails" option is for?

@ToBeFree - I thought it just blocked the user from sending email. I'm confused; what do you mean exactly? Since this option can only be applied to an account being blocked, does the block sending email also trigger something else? Maybe in combination with autoblocking the IP address?

This comment was removed by Steel1943.

(This refers to the comment from @Aklapper above. There were portions of the comment I felt needed to be suppressed, so I'm reposting what I felt was relevant.)

I recently discovered this issue which this ticket refers on the English Wikipedia at https://en.wikipedia.org/wiki/Help_talk:Reset_password#Why_is_Special:PasswordReset_blocked_for_blocked_IP_ranges%3F . Seems this has been a known issue that needs resolved for ... almost 7 years, and hasn't been fixed yet? Is there any way to increase the priority for this to get fixed? (I'm not too familiar with how to do that on Phabricator.)

Isn't this what the "block sending e-mails" option is for?

Since this option can only be applied to an account being blocked

In which MediaWiki installation?

Is there any way to increase the priority for this to get fixed?

Demonstrate clear community agreement on what to do. It seems like this is technically easy, the main problem is getting everyone to agree that it should be fixed.

With "block sending e-mails" existing for exactly this purpose, there is no need to reinvent the wheel, no need to add a new option to the blocking menu, no lack of a tool to selectively prevent password resets for abusive ranges. All that's needed is a bugfix: Without "block sending e-mails", don't block sending e-mails.

"block sending emails" primary purpose would arguably be to prevent using Special:EmailUser, not accessing password reset functions....

An anon-only email block on an IP address is unlikely to have any meaning other than the here-desired one, as Special:EmailUser is not available to logged-out users by default and in probably almost all MediaWiki configurations.

An anon-only email block on an IP address is unlikely to have any meaning other than the here-desired one, as Special:EmailUser is not available to logged-out users by default and in probably almost all MediaWiki configurations.

Sure this is one view - however what is needed is not the expression of the view but evidence it is widely held by the community.

I was led into this task by this conversation. As you'll find explained in details in the link, this adds an increased degree of difficulty to what was already a very confusing experience for new users.

To put it very shortly: Most of them have no idea what IP editing or range blocks are. Some of them are users who for different reasons have difficulties using a computer to begin with. This makes it an almost impossible task for them to regain control and editing rights on their accounts if they were unfortunate victims of a range block (which we know to be a lot for every range block). Again, you'll see all this explained in the link above, coupled with real life examples.

I understand the problem of request spamming but I really wish we wouldn't put all the weight of this on new users' backs. If anything, admins and veteran users should be holding most of it until a better solution was found. We're talking about losing potential new volunteers. This is already a risk with range blocks per se but this just makes it worse.