Last modified: 2009-12-30 05:06:26 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.
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.
(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?
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?
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.
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.
(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.)
(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.
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.
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.
(Open a new bug for the specific shell request)
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.
