Wikimedia Bugzilla is closed!

Can't you just filter them?
Seems I was wrong in closing bug 8460 :/

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...

(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.

Maybe a captcha would do the trick.

(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.

Well, in that case, a good start would be to limit it to one or two emails per day.

(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.

(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.

(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.

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 also fully support this feature and am getting these requests also. Surely such activity as requesting someone's password is also a legal issue? 

(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.

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

(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.

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.

(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.

> 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;

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?

(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.

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.

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.

(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)?

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?