Problem
When requesting a new password within a 24 hour period, you get this error:
A password reset email has already been sent, within the last 24 hours. To prevent abuse, only one password reset email will be sent per 24 hours.
Solution
Consider increasing the throttle substantially (maybe once an hour? or every 5 minutes?)
What kind of abuse is this preventing?
T7370: Throttle password reminder requests. See also T9078: A throttle to new password requests for Wikimedia wikis and T19487: mail password per user rate limit should be global for SUL accounts.
And is the abuse worse than preventing a legitimate user workflow?
Probably, since that seems like a very strange and hacky workflow. The password reminder isn't meant to be a "login via email" feature.
See also https://xkcd.com/1172/
Or at a minimum, increase it substantially (maybe once an hour? or every 5 minutes?)
I'll let others decide whether decreasing it to that extent would prevent the abuse, or whether this task should be declined.
Some notable sites do not even have passwords — all login is done via email or OAuth. It's a valid design choice, but not one MediaWiki currently supports.
I agree we need a throttle, but 24 hours seems pretty steep. We looked for any existing discussions but did not find any that weighed 24 hours vs. a lower throttle.
I can't say I've ever come across a site that only allows login via receiving an email every time you log in or using OAuth. Do you have specific examples of these notable sites?
but not one MediaWiki currently supports.
Someone could make an extension to do this now that we have AuthManager. It probably wouldn't even be that complicated. I'd be skeptical of it passing Security for enabling on WMF wikis though.
https://medium.com/ — but it looks like they've passed the buck even further and only allow new accounts to register via OAuth. My account is still email only.
Seems like there's two threads here:
I stumbled across this thread while aimlessly browsing the web. I'll let you judge if it counts as notable but if you'd like an example, this site only allows login by emailing a link to you:
I'm having difficulty understanding why someone would abuse this feature of someone else. If you already have to know someone's email to use it, why wouldn't you just send an email to them directly?
Was this implemented before an email address was required to reset a password?
Or are these bots that are abusing this feature? If so, perhaps we could just require a CAPTCHA on the second attempt?
If you already have to know someone's email to use it
You don't have to know someone's email to use it, you can trigger a password reset by supplying the user name.
why wouldn't you just send an email to them directly?
Because "you" (the attacker) don't know that the email it sends them includes your IP address. Because the victim can't as easily block mail from Wikipedia as they could email from some random address belonging to the attacker. Because it's easier to keep resubmitting a form where you only have to enter one thing than to go through some webmail provider's workflow for composing and sending a message.
Or are these bots that are abusing this feature?
It seems to have been disgruntled users, not bots.
Oh... the form implies that both fields are required, so I assumed that was the case.... maybe they should be?
email from some random address belonging to the attacker
An attacker can just create random addresses, which would be hard to block as well. But is there even any evidence of this? Given that you do not need their email address, it makes perfect sense that they would just be using this feature with the username.
Alternatively, completely removing the Usernamefield I think would eliminate the abuse.
In this scenario, you'd only be able to reset your password if you know the email address associated with your account, but you do not have to know your username (which some people may have forgotten anyways).
Then how would a password reset work for an email that is associated with multiple accounts?
What does the form do know if you just put in an email address? Does it send a reset to every account?
This thought process is so backwards I'm baffled. You want to cripple existing, useful functionality to support some bizarre passwordless email login scheme??
If people are using it to abuse others, is it really that useful? Especially when you have to know the email address anyways? Like, ok, I put in my username... hmm, now I have to go check my email... which one?
It only solves the use case of people not knowing which email their user is attached to, and in that case, they're going to have to go check multiple emails anyways. Why not have these users just try each address they have?
Well then to support your use case I think we should:
Make Email required (and the first field) and Username optional.
Doing this would prevent the harassment as well as allow us to remove the arbitrary throttle.
People aren't abusing it now, because we've had a throttle on it for 10 years.
The only one here advocating for changing that is you, based on your bizarre passwordless email login scheme that doesn't even have a good user interface (trigger email, get email, click link, be forced to reset your password that you have no intention of using).
Let's keep this conversation constructive. There are a few worthwhile topics to discuss:
For topic #1 — I acknowledge and agree that a throttle is needed to prevent abuse. And upon further testing, I do not believe we need to alter the 24-hour throttle because the temporary password functions for 24 hours and the throttle is reset when the password is updated by the user.
I believe that topics #2 and #3 could bring usability improvements but would best benefit from a product team (e.g. product manager, interaction designer, developers, community manager) to think thoroughly about all the requirements and corner cases, given the history and complexity of MediaWiki/Wikimedia's user account infrastructure. If David or anyone else thinks these topics are worthwhile to further explore, I would recommend they create a new Phabricator task(s) to propose these as changes to existing functionality, rather than as a defect to the current system.
Thank you for this summary.
It looks like this task can now be closed. Any objections?