Last modified: 2011-04-14 15:10:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 17487 - mail password per user rate limit should be global for SUL accounts
mail password per user rate limit should be global for SUL accounts
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
CentralAuth (Other open bugs)
unspecified
All All
: Low enhancement with 7 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 9816
  Show dependency treegraph
 
Reported: 2009-02-13 22:51 UTC by Al Tally
Modified: 2011-04-14 15:10 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Al Tally 2009-02-13 22:51:06 UTC
As of late I've been having dozens of emails for password reminders, all from two IP ranges, and the same user. This is becoming extremely irritating, and would like a feature that perhaps stewards could use to globally block IPs/ranges from abusing this feature.
Comment 1 Platonides 2009-02-13 22:54:08 UTC
Can't you just filter them?
Seems I was wrong in closing bug 8460 :/
Comment 2 Al Tally 2009-02-13 22:57:16 UTC
I don't think so. It should be easy to request to a steward to global block the IP's ability to abuse this feature. I should not have to mess about with my filter because of some psycho obsessed with requesting my password...
Comment 3 Mike.lifeguard 2009-02-13 23:04:01 UTC
(In reply to comment #2)
> I don't think so. It should be easy to request to a steward to global block the
> IP's ability to abuse this feature. I should not have to mess about with my
> filter because of some psycho obsessed with requesting my password...
> 

Agreed - this is abused more frequently than one might think. Some solution should be offered.
Comment 4 Thomas Bertels 2009-02-17 21:18:50 UTC
Maybe a captcha would do the trick.
Comment 5 Mike.lifeguard 2009-02-17 22:15:44 UTC
(In reply to comment #4)
> Maybe a captcha would do the trick.
> 

No, these are humans. Often it's a serial vandal the admin has blocked. To get revenge they'll send dozens (hundreds in some cases) of password reset emails to the admin. A CAPTCHA will slow them down only (and you can imagine that someone who is so bored they would take the time to send hundreds of such emails would solve the CAPTCHAs and keep on going). The whole point is to *stop* them.
Comment 6 Thomas Bertels 2009-02-17 22:19:46 UTC
Well, in that case, a good start would be to limit it to one or two emails per day.
Comment 7 Al Tally 2009-02-17 22:22:44 UTC
(In reply to comment #6)
> Well, in that case, a good start would be to limit it to one or two emails per
> day.
> 

Or none at all, from certain IPs, if they abuse it.
Comment 8 Mike.lifeguard 2009-02-17 22:24:30 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > Well, in that case, a good start would be to limit it to one or two emails per
> > day.
> > 
> 
> Or none at all, from certain IPs, if they abuse it.
> 

That's the key. Allowing slow abuse instead of fast is not the solution (and could conceivably block legitimate use of the feature). We should really be able to block the IP from just email bombing via Special:UserLogin on an as-needed basis.
Comment 9 Thomas Bertels 2009-02-17 22:32:52 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > > Well, in that case, a good start would be to limit it to one or two emails per
> > > day.
> > > 
> > 
> > Or none at all, from certain IPs, if they abuse it.
> > 
> 
> That's the key. Allowing slow abuse instead of fast is not the solution (and
> could conceivably block legitimate use of the feature). We should really be
> able to block the IP from just email bombing via Special:UserLogin on an
> as-needed basis.
> 

Sure, but since IPs are mostly dynamic, the admin would have to ask it to a steward... each time (each day or more often if the bombers change their IPs).
So, with one or two emails per day (or per 7 days, since the new password is good for that time), the admin could get even less emails than with IP blocking.
Comment 10 OverlordQ 2009-02-17 22:45:09 UTC
Well it's limited to one every 24 hours out of the box, is this disabled on WMF wikis or have a lower delay? 

See r17217
Comment 11 fr33kman 2009-02-18 17:04:28 UTC
I also fully support this feature and am getting these requests also. Surely such activity as requesting someone's password is also a legal issue? 
Comment 12 Thomas Bertels 2009-02-18 18:04:02 UTC
(In reply to comment #10)
> Well it's limited to one every 24 hours out of the box, is this disabled on WMF
> wikis or have a lower delay? 
> 
> See r17217

I can confirm that it works.

(In reply to comment #11)
> I also fully support this feature and am getting these requests also. Surely
> such activity as requesting someone's password is also a legal issue? 

I really don't think that blocking IPs would be useful, unless the requests are triggered by the same IPs for more than a day.

Maybe inscreasing the minimum time between requests to the new password lifespan (7 days) could be considered.
Comment 13 MZMcBride 2009-02-18 18:10:17 UTC
On Wikimedia wikis, I believe this is the relevant info:

'wgRateLimits' => array(
    'default' => array(
        'mailpassword' => array(
            // 5 password reminders per hour per IP
            'ip'     => array( 5, 3600 ),
        ),
    ),
),

From http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php
Comment 14 Mike.lifeguard 2009-02-18 21:08:21 UTC
(In reply to comment #13)
> On Wikimedia wikis, I believe this is the relevant info:
> 
> 'wgRateLimits' => array(
>     'default' => array(
>         'mailpassword' => array(
>             // 5 password reminders per hour per IP
>             'ip'     => array( 5, 3600 ),
>         ),
>     ),
> ),
> 
> From http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php
> 

OK, so this is just a shell request I guess. Can we please have something like

//5 password reminders per 2 days per IP
'ip' => array(5, 172800),

I don't think that'd pose any problems for people who have legitimately lost their password.
Comment 15 MZMcBride 2009-02-18 21:43:52 UTC
I believe the rate is intentionally as 'high' as it is because there were legitimate uses of the password reset feature being hit so many times per IP in an hour (e.g., shared IPs).

I think the correct answer here is to complement the current system with a number of hits per requestee per day, a limit which could be pretty low and not harm anything, in my opinion.
Comment 16 Mike.lifeguard 2009-02-18 22:12:47 UTC
(In reply to comment #15)
> I believe the rate is intentionally as 'high' as it is because there were
> legitimate uses of the password reset feature being hit so many times per IP in
> an hour (e.g., shared IPs).
> 
> I think the correct answer here is to complement the current system with a
> number of hits per requestee per day, a limit which could be pretty low and not
> harm anything, in my opinion.
> 

Ahh, of course. I'll revert my changes to the summary etc then. The limit should indeed be on the user for which the password is being requested, not on the IP. I suppose I conflated the two.
Comment 17 Platonides 2009-02-18 22:40:31 UTC
> The limit should indeed be on the user for which the password is being requested, not on
> the IP. I suppose I conflated the two.

That limit is currently a day.

/**
 * Minimum time, in hours, which must elapse between password reminder
 * emails for a given account. This is to prevent abuse by mail flooding.
 */
$wgPasswordReminderResendTime = 24;
Comment 18 JeLuF 2009-02-21 17:23:58 UTC
With the current settings, only 1 new password can be sent per day and account. I think that covers the above requirements. Is there still any need to change anything or can this be closed?
Comment 19 Al Tally 2009-02-21 17:43:45 UTC
(In reply to comment #18)
> With the current settings, only 1 new password can be sent per day and account.
> I think that covers the above requirements. Is there still any need to change
> anything or can this be closed?
> 

Not when the requester requests across multiple projects.
Comment 20 Platonides 2009-02-21 21:03:28 UTC
Changing summary again.
globaluser table doesn't have a gu_user_newpass_time field, but gu_password_reset_expiration can be used for that same purpose.

How painful would be removing gu_password_reset_expiration and adding gu_user_newpass_time?
Column changes are always an annoyance but using different semantics to achieve the same suck.


Comment 21 MA 2009-04-04 18:52:45 UTC
I'm being e-mail bombed right now by password reminders. Blocked IP adresses in a project e.g.: meta, can't use the "password reminder" feature. I've blocked an IP adress http://meta.wikimedia.org/w/index.php?title=Special%3ALog&type=block&user=&page=User%3A87.122.104.173&year=&month=-1, then the owner of this IP adress tryied to use the feature and got the following message: "Login error: Your IP address is blocked from editing, and so is not allowed to use the password recovery function to prevent abuse." The problem is that this vandals switch between projects and abuse them on all of them. A feature avalaible to stewards should be implemented to block an IP adress to send e-mail reminders as well as a dayly limit of reminders. Cheers.

Comment 22 Mike.lifeguard 2009-06-27 23:09:32 UTC
(In reply to comment #20)
> Changing summary again.
> globaluser table doesn't have a gu_user_newpass_time field, but
> gu_password_reset_expiration can be used for that same purpose.
> 
> How painful would be removing gu_password_reset_expiration and adding
> gu_user_newpass_time?
> Column changes are always an annoyance but using different semantics to achieve
> the same suck.
> 

So then there's nothing to do on shell (unless I misunderstand)?
Comment 23 Platonides 2009-06-27 23:32:36 UTC
You're right.

First we need to agree which field is going to be used.

Then it needs to be coded.

Domas/Tim would that be an acceptable schema change?

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links