Page MenuHomePhabricator

ConfirmEdit should block IPs after a set number of failed CAPTCHA attempts
Closed, ResolvedPublic

Description

Author: carlb613

Description:
While $wgCaptchaBadLoginAttempts appears to activate CAPTCHA after a certain number of bad password attempts are made for an existing account, there needs to be some means of blocking an IP for repeatedly giving random answers to the CAPTCHA itself.

Bots routinely try to play the odds ([[bugzilla:40496]] mentions 4096 possiblities in Asirra, twelve photos with two possibilities, cat or dog, apiece - mw:Extension:VisualMathCaptcha or other simple maths problems in their default configurations are worse still as a random answer to a two-digit sum will be correct 1% of the time).

If the offending IP landed on the block list (and mw:extension:GlobalBlocking if installed) on the third failed CAPTCHA attempt, spammers would be less tempted to try to guess their way past these systems.

There needs to be a way to detect repeated failures (such as dictionary attacks) in much the same way as mw:extension:AbuseFilter can implement three-strikes rules for ongoing vandalism. ([[bugzilla:34913]] raised the issue that AbuseFilter does not have a mechanism to receive reports from other extensions for things like repeated CAPTCHA failures, so its counters can't be used directly here.)


Version: master
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=34914

Details

Reference
bz46292

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:27 AM
bzimport set Reference to bz46292.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Mar 18 2013, 6:24 PM

Ratelimits can be a possible way to implemt this (Using User::pingLimiter and $wgRateLimits). Should be done on showing captcha and maybe another limit on resolving captchas? Or one limit for both, that should also be okay.

This is probably the most important security hole in our captcha, I wouldn't call it a feature request.

Florian claimed this task.Jan 2 2015, 10:41 PM

I think the best is to use wgRateLimits, because it's a built in MediaWiki function and therefore is no need to add a dependency to other extensions in order to use ConfirmEdit with this function :)

Change 182551 had a related patch set uploaded (by Florianschmidtwelzow):
Add RateLimit check for false CAPTCHAs

https://gerrit.wikimedia.org/r/182551

Patch-For-Review

Change 182551 merged by jenkins-bot:
Add RateLimit check for false CAPTCHAs

https://gerrit.wikimedia.org/r/182551

With the above patch (merged in ConfirmEdit and will be deployed with 1.25wmf21, see https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap for dates and status), ConfirmEdit supports ratelimiting to prevent an action after an configured amount of false CAPTCHA tries. It is deactivated by default, so if we want to enable it on wmf-wikis, we need to configure it. Should we? :)

Florian closed this task as Resolved.Mar 10 2015, 7:21 AM

It is deactivated by default, so if we want to enable it on wmf-wikis, we need to configure it. Should we? :)

Absolutely yes.

Nemo_bis set Security to None.
gpaumier edited projects, added User-notice; removed Notice.Mar 13 2015, 10:13 PM
gpaumier moved this task from To Triage to Not ready to announce on the User-notice board.