Last modified: 2009-01-13 11:18:49 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 11354 - Special:MergeAccount does not prompt for a captcha after an incorrect password is entered
Special:MergeAccount does not prompt for a captcha after an incorrect passwor...
Product: MediaWiki extensions
Classification: Unclassified
CentralAuth (Other open bugs)
All All
: High normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: crosswiki
Depends on:
Blocks: 9816
  Show dependency treegraph
Reported: 2007-09-15 21:02 UTC by Tra
Modified: 2009-01-13 11:18 UTC (History)
2 users (show)

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

Screenshot showing the error message at (150.33 KB, image/jpeg)
2009-01-13 11:18 UTC, Happy-melon

Description Tra 2007-09-15 21:02:45 UTC
It is possible for the password of an account on any Wikimedia wiki to be compromised by a brute-force attack as long as the same account name does not exist on test wiki.

Steps that could be taken by an attacker:
1. Register the desired account name on
2. Visit and enter their password when prompted.
3. Run a bot to conduct a brute force attack by entering various possible passwords in the 'Confirm more accounts' section until they have been told that they have the correct password for any of the accounts listed.
4. Use the password that is known to work to log in normally at the relevant login page.

To resolve this problem, a captcha should be added to all password prompts at [[testwiki:Special:MergeAccount]] after an incorrect password is entered, or alternatively the page could be disabled temporarily since it is only there as a test/demo.
Comment 1 Happy-melon 2009-01-12 18:26:23 UTC
This is invalid: attempting to reproduce, I do the following:

* Find an unblocked account on that is not a global account
* Register that username on
* Go to [[test:Special:MergeAccount]] and enter my password
* An error message comes up, and I cannot proceed. 

CentralAuth first checks that the password is correct for the wiki you're merging from ( in this case), but it then checks that the password is the same as on your home wiki ( in this case).  Since they don't match, and you can't alter them so they ''do'' match (or you wouldn't be going through this rigmarole!) you can't proceed.  The bug is invalid as written.

What **might** be possible is A) repeatedly changing the password on the account and attempting the merge process again. Do we throttle password changes?  Alternatively, you could create an account and then develop it so that it *becomes* the home wiki. However, I doubt this is practical: certainly for accounts with extra rights you would need an account at least as well-flagged, if there's a ne'er-do-well in control of such on *any* wikimedia wiki we have a problem, never mind the faint possibility of brute-forcing a password.  

The simple solution, of course, is to complete the SUL merge process so that there **aren't** any accounts with missing SUL partners.  New accounts are automatically registered on all CentralAuth wikis, so this is only a potential issue with the old unmerged accounts.
Comment 2 Mark Ryan 2009-01-13 01:48:39 UTC
I think you (Happy-melon) might misunderstand how Special:MergeAccount works. When I go to it on en.wp, it presents me with 27 accounts which have already been merged, and a list of more than 40 wikis where there is a 'Mark' account which could not be merged. If I type a password into the box at the bottom, it checks all of those outstanding accounts to see if the password matches what I typed in. If none have a matching password, it returns me to the page and says "No accounts could be confirmed using this password." -- I can then try another password immediately. The password you supply does not have to match the password for the account on the wiki you're merging from; that way you can merge accounts which are your own but which have different passwords. So brute force seems possible. But by the same token you can't register a new account with the same username as someone else, so the chances for misuse of this are minimal.
Comment 3 Happy-melon 2009-01-13 11:18:49 UTC
Created attachment 5666 [details]
Screenshot showing the error message at

Indeed, but that's because is your home wiki, where you have the longest-standing account with the highest permissions and the most productive edits.  If you go to *another* wiki and try the same process, as the bug suggests, it doesn't work, because the password you use *does* have to match your *home wiki* password.  So the only people who could take advantage of this situation are people who already own a *more* 'respectable' account with the *same name* as the target account on another wikimedia wiki.  Sounds fairly implausible to me.

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