Last modified: 2009-12-30 05:06:26 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 T12284, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 10284 - Captchas on Special:Userlogin and bots
Captchas on Special:Userlogin and bots
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/Special:Userl...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-15 22:59 UTC by Dan Collins
Modified: 2009-12-30 05:06 UTC (History)
5 users (show)

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


Attachments

Description Dan Collins 2007-06-15 22:59:53 UTC
Special:Userlogin uses a captcha to prevent automated logins, every failed login attempt results in a captcha being added for 5 minutes, This is an excellent security tool, but does cause some problems, especially with robots. Usually, there would be no problem, as a captcha is rare on most systems. However, on the toolserver, it is displayed surprisingly often, preventing all wikipedia bots from that source from logging in, and causing various issues. There are two ways around this, and they are:

1: Exempt the toolserver's IP from the captcha, simply do not set the captcha to activate on bad logins from toolserv. This would not be dangerous, as the toolserver is not publicly accessible, and would not be used to attack user's accounts.

2: Exempt all bots. Whatever the process is that verifies the captcha, first should check if the bot is flagged. This would allow external users to attack bot accounts, however.

3: Reactivate the login API for registered bots (those with the botflag). Also allows external users to attack bot accounts, but bot owners could be asked to 'opt-in' their bot for API login, and only bots on this list can login through this method. This would allow only operators who have been told to set a secure 12+ character password to use the API, which would cripple any password attacks. This opt-in would have to be done while logged in, to prevent malicious users adding a target account to the list. This has the bonus that non-flagged bots, both those intentionally unflagged and those in trial, can still use the process.

This bug prevents bot usage and testing, and should be corrected if possible.
Comment 1 Rob Church 2007-06-16 01:02:22 UTC
1. Perhaps doable, although I don't know if we have a per-IP whitelist as coded.

2. Not a good idea...a bot account has a little more leeway and is not so immediately noticeable if compromised.

3. The login API was disabled because it was insecure. Re-enabling it won't happen again until this is fixed; there is potential for bot account passwords to be leaked.
Comment 2 E 2007-06-16 09:51:04 UTC
(In reply to comment #1)
> 1. Perhaps doable, although I don't know if we have a per-IP whitelist as
> coded.
>
Is there any other way to disable CAPTCHA for the particular IP address only or will it need to be created?
Comment 3 Dan Collins 2007-06-16 11:13:05 UTC
E: It would need to be created. I'm not at all fluent in PHP, however, I think it would be quite simple.

Rob:
You say that it would be hard to detect if it is compromised, what if we used a 'opt-in' list of bot operators who want to use it and have status that they have a 16+ alphanumeric password? That leaves about 8 octillion possibilities, and even it every person on the planet attacked it, each person would have a list of passwords ranking in the hundreds of trillions, and a bot can remember such a password, whereas a human cannot. Even if not, toolserver can probably be exempted safely, correct? 
Comment 4 Huji 2007-06-16 17:58:08 UTC
Dan, that kind of inclusion criteria for the "opt-in" system doesn't seem to be feasible indeed. I may run a bot now with a 42 letter alphanumeric-digit-special-char password, opt in the list, then change my password to something more easy for myself, just because I'm too lazy to use that long password! I made an exagerated example, but I'm sure you know what I mean.
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-17 01:51:42 UTC
We need more flexible password strength requirements, as part of the core software, that are triggered whenever users change their password.  Sysops and bots need more secure passwords, of course.  Users with sufficiently secure passwords could be given the right to waive the captcha for themselves.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-17 02:13:13 UTC
(In reply to comment #5)
> We need more flexible password strength requirements, as part of the core
> software

(Never mind the part about in the "core software", an extension is fine.)
Comment 7 Chad H. 2007-07-16 18:56:47 UTC
(In reply to comment #1)
> 1. Perhaps doable, although I don't know if we have a per-IP whitelist as
> coded.
> 

After reading through ConfirmEdit.php, it turns out we *do* have a whitelist, stored in an array titled $wgCaptchaWhitelistIP.

Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-16 19:18:24 UTC
Now we do, although we didn't at the time comment #1 was made.  (bug 10424)  It's IP-specific, of course, not user-specific.
Comment 9 Chad H. 2007-07-16 19:35:33 UTC
Implementing a user-specific one seems as though it'd be a bad idea, as Rob pointed out above with regards to accounts being compromised. However, as this request is in regards to the toolserver specifically, I think it could easily be added to the whitelist, solving this issue.
Comment 10 Rob Church 2007-08-31 15:21:05 UTC
(Open a new bug for the specific shell request)
Comment 11 Roan Kattouw 2008-09-06 21:52:01 UTC
Closing as FIXED because the login API has been re-enabled ages ago, and nobody's replied to this bug for a year. Please REOPEN if this is still an issue.

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


Navigation
Links