Last modified: 2011-12-24 22:49:10 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 28747 - AntiSpoof should also check global accounts from CentralAuth
AntiSpoof should also check global accounts from CentralAuth
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
CentralAuth (Other open bugs)
unspecified
All All
: High enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: platformeng
: 15545 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-04-29 17:02 UTC by SoWhy
Modified: 2011-12-24 22:49 UTC (History)
6 users (show)

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


Attachments

Description SoWhy 2011-04-29 17:02:54 UTC
If you try to create an account that is similar to an existing one (such as me trying to create "SöWhy"), the software will check for existing usernames (here "SoWhy") and disallow creation of the account. On the other hand, if you create the account "SöWhy" on another project that the "SoWhy"-account does not exist yet, you can then auto-create the account on the wiki the "SoWhy" account already exists, thus creating an impersonation account despite the measures set in place to prevent this.

Example: 
- http://toolserver.org/~vvv/sulutil.php?user=SoWhy
- http://toolserver.org/~vvv/sulutil.php?user=S%C3%B6Why

Regards,
SoWhy
Comment 1 Platonides 2011-04-29 19:18:16 UTC
AntiSpoof does not work with CentralAuth currently.

This could work on two ways: by blocking the account autocreation if there's a local account with similar name, or by blocking registration if there is a similarly named global account.

I think the later is preferable.
Comment 2 SoWhy 2011-04-29 19:33:39 UTC
Blocking autocreation would probably not work without heavy modifications, also that would still allow impersonation of prominent users on little known side projects, for example by claiming to be an en-wiki admin on en-wikiversity. 

On a side note, AntiSpoof probably needs to be improved as well, as seen in the recent attack of impersonation accounts on en-wiki. For example, AntiSpoof does not block the creation of usernames with a single character changed unless that character is similar to the changed one ("SöWhy" is blocked but "SüWhy" is not). On a short username like mine, a change of a character is easily noticed but if the username has 15+ characters or if the username is complicated, many people will not notice the change, so it would probably be good if AntiSpoof checked how much the new username has in common with existing ones.
Comment 3 Krinkle 2011-05-01 13:06:30 UTC
(In reply to comment #1)
> AntiSpoof does not work with CentralAuth currently.
> 
> This could work on two ways: by blocking the account autocreation if there's a
> local account with similar name, or by blocking registration if there is a
> similarly named global account.
> 
> I think the later is preferable.

Changed bugsummary accordingly


(In reply to comment #2)
> not). On a short username like mine, a change of a character is easily noticed
> but if the username has 15+ characters or if the username is complicated, many
> people will not notice the change, so it would probably be good if AntiSpoof
> checked how much the new username has in common with existing ones.

I'm not sure how valid this request is (even just FoobarLand and FoobarBand are very different imho), but you could request this, as a seperate bug.
Comment 4 Krinkle 2011-05-02 20:59:50 UTC
Moved and assigned per BugTriage.
Comment 5 Mark A. Hershberger 2011-07-06 17:00:34 UTC
Removing from 1.18 deployment blocker but bumping priority to compensate.
Comment 6 Rob Lanphier 2011-07-28 21:14:34 UTC
Sam, is this something you can look into?
Comment 7 Sam Reed (reedy) 2011-12-20 17:18:51 UTC
r106805, r106808 were prequisite work (refactoring etc)

r106809 and r106812 then build on that, and use the stuff

Some more updating in r106813, r106816 to bring the maintenance script into recent shape and create a CA script for it also


Pushing bug back into CA component, as it's done essentially on the CA side
Comment 8 Sam Reed (reedy) 2011-12-20 19:16:31 UTC
Some other bits of cleanup work also done to AntiSpoof

Need to do a bit of testing to check it
Comment 9 Sam Reed (reedy) 2011-12-24 22:48:39 UTC
*** Bug 15545 has been marked as a duplicate of this bug. ***
Comment 10 Sam Reed (reedy) 2011-12-24 22:48:57 UTC
Marking as fixed!

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


Navigation
Links