Last modified: 2008-08-14 00:50:39 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 14630 - Log password email reset requests in the CU log
Log password email reset requests in the CU log
Product: MediaWiki extensions
Classification: Unclassified
CheckUser (Other open bugs)
All All
: Normal enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2008-06-24 15:00 UTC by Larry Pieniazek
Modified: 2008-08-14 00:50 UTC (History)
10 users (show)

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


Description Larry Pieniazek 2008-06-24 15:00:40 UTC
The system provides a way to reset a user password via email, which is goodness. But it can be used to annoy users, since anyone can request it from the login screen for any user. The IP of the requestor is tracked in the email. 

Suggest that this IP also be tracked in a log accessible by CUs for the relevant wiki, per discussion on the CU list.
Comment 1 FT2 2008-06-24 16:00:14 UTC
Confirming the discussion and supporting the request.
Comment 2 Brian McNeil 2008-06-24 17:58:22 UTC
I fully support this, there won't be a huge amount of use for it but if there's "requested password for xxx" in the CU log it will reveal abusers.
Comment 3 Alison Cassidy 2008-06-24 18:34:10 UTC
This would definitely be useful. As checkuser, I also get a large number of these on a good day.
Comment 4 Jeffrey Quisenberry 2008-06-24 19:21:26 UTC
Can we do this in a way that primarily tries to reduce the abuse? Perhaps we could include a statement in the web page, either before or after the reset request is made, that this request will be/has been logged in a manner accessible only by [[m:CheckUser policy|checkusers]], who are required to protect the privacy of requests but may review the log for abuse. In other words, nothing more than what people should expect webmasters to do, but a clear message to those who use this only to abuse. As a checkuser myself, I'll take the discovery tool, but would prefer prevention.
Comment 5 Nicolas Dumazet 2008-06-24 20:19:08 UTC
Suggesting a new hook at the end of SpecialUserlogin::mailPassword.

This hook would need imo $u as a parameter (the user that just got its password reset), and a reference to a String, the message to display instead of wfMsg('passwordsent' ...), if the hook returns true. This would allow the preventive message suggested in comment #4 to be displayed.

How does it sound ?
Comment 6 Aaron Schulz 2008-08-12 23:56:29 UTC
Since this would only be marginally useful, given that the IP is in the spam emails, I'm not sure if this is worth implementing.
Comment 7 Larry Pieniazek 2008-08-13 00:04:45 UTC
see comments 1-4 as to why this is useful, and more than marginally... the IP in the email means that different people have to figure out who they should talk to. Logged, its easy to see a pattern of abuse. Maybe this should be debated on the CU list but the request was made after multiple CUs said it would indeed be useful and multiple CUs supported it after that.
Comment 8 Aaron Schulz 2008-08-13 00:10:34 UTC
Yes, I saw the comments, but no rationale.
Comment 9 Siebrand Mazeland 2008-08-13 18:18:10 UTC
Rationale is that in case of account stealing a recently logged password reset request per e-mail is very relevant.
Comment 10 Aaron Schulz 2008-08-14 00:50:39 UTC
Done in r39322. Will be discussed some before in enabling.

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