Last modified: 2013-05-04 05:07:51 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T48590, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 46590 - Extensions can't fully block password changes
Extensions can't fully block password changes
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
unspecified
All All
: Unprioritized normal (vote)
: 1.20.x release
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-27 05:12 UTC by Ryan Lane
Modified: 2013-05-04 05:07 UTC (History)
8 users (show)

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


Attachments
Patch to add AbortChangePassword hook (4.61 KB, patch)
2013-03-27 05:17 UTC, Ryan Lane
Details
Updated and tested patch (4.61 KB, patch)
2013-03-27 16:07 UTC, Ryan Lane
Details
patch for 1.19 (4.07 KB, patch)
2013-04-30 16:01 UTC, Chris Steipp
Details

Description Ryan Lane 2013-03-27 05:12:13 UTC
Special:PasswordReset can block password changes using the AbortLogin hook, and Special:ChangePassword can block password changes via $wgAuth->authenticate. The combination of these two approaches can work, but some extensions only implement one method or the other (and in some cases shouldn't implement both).

Lack of a consistent method for handling this leads to unexpected situations where a password can be changed, even though the extension author feels they are blocking it.

A hook should be added to Special:ChangePassword for this functionality.
Comment 1 Ryan Lane 2013-03-27 05:17:19 UTC
Created attachment 11991 [details]
Patch to add AbortChangePassword hook

Patch still needs proper testing. Submitting for feedback.
Comment 2 Ryan Lane 2013-03-27 16:07:05 UTC
Created attachment 11997 [details]
Updated and tested patch

One minor fix in patch. Has been tested and is working.
Comment 3 Chris Steipp 2013-03-27 18:21:26 UTC
Patch looks fine to me. I don't think the bug this fixes effects security (unless I'm missing something?), so I think we should make it public, put it in gerrit, and make sure other developers are on board with it.
Comment 4 Chris Steipp 2013-03-27 20:58:18 UTC
This bug does allow for two-factor authentication (OATHAuth) to be bypassed by doing a password reset, if the attacker also has access to the victim's email.

This doesn't affect the cluster, so no need to patch there, but we'll add this to the next security release.
Comment 5 Chris Steipp 2013-04-30 16:01:22 UTC
Created attachment 12210 [details]
patch for 1.19
Comment 6 Gerrit Notification Bot 2013-04-30 20:17:55 UTC
Related URL: https://gerrit.wikimedia.org/r/61631 (Gerrit Change I3469e90a958c4fb0f24cafd67de5590d3cc2f075)
Comment 7 Gerrit Notification Bot 2013-04-30 20:53:43 UTC
Related URL: https://gerrit.wikimedia.org/r/61641 (Gerrit Change I3469e90a958c4fb0f24cafd67de5590d3cc2f075)
Comment 8 Gerrit Notification Bot 2013-04-30 20:58:37 UTC
Related URL: https://gerrit.wikimedia.org/r/61644 (Gerrit Change I3469e90a958c4fb0f24cafd67de5590d3cc2f075)
Comment 9 Gerrit Notification Bot 2013-05-04 05:07:51 UTC
Related URL: https://gerrit.wikimedia.org/r/62216 (Gerrit Change I3469e90a958c4fb0f24cafd67de5590d3cc2f075)

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


Navigation
Links