Last modified: 2009-01-13 11:18:49 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 test.wikipedia.org 2. Visit http://test.wikipedia.org/wiki/Special:MergeAccount 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.
This is invalid: attempting to reproduce, I do the following: * Find an unblocked account on en.wiki that is not a global account * Register that username on test.wiki * 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 (test.wiki in this case), but it then checks that the password is the same as on your home wiki (en.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 test.wiki 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.
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.
Created attachment 5666 [details] Screenshot showing the error message at test.wiki Indeed, but that's because en.wiki 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.
