Topic on Extension talk:ConfirmEdit

Spambots today have no problem getting past SimpleCaptcha. Time to adapt, I think. Regards,

Agreed... I just finished removing it from a pile of Uncyclopedia languages for this very reason and have updated this page accordingly (to suggest migration to VisualMathCaptcha or one of the others).

ReCAPTCHA is problematic for sites in foreign languages with non-Latin character sets as the captchas themselves are taken from old books in a limited selection of languages. English and French are there, Ukraine and Japan might not be.

Nonetheless, I note this page claims:

• Part of the weakness of the ReCaptcha module is that ConfirmEdit doesn't include any penalty mechanism, so spam bots can simply keep trying to bypass the CAPTCHA until they get through. This is an issue that is strongly worth addressing in some way.

Perhaps this should be reported as a bug for *all* categories of CAPTCHA, especially the trivial maths problems. I could very arbitrarily decide to submit spam, code a script to presume the answer is 6, then send the same rubbish repeatedly and be challenged with different CAPTCHA images until the answer to one just happened to be six... spam, spam, it's better than ham. Changing the code to autoblock an IP after a few failed attempts would greatly cut down that risk. --Carlb (talk) 01:39, 2 March 2012 (UTC)

It would be a nice addition to Extension:AbuseFilter.

It's worse. Even ReCaptcha is worked out by spambots. At translatewiki, we're using ReCaptcha with extension:SimpleAntiSpam and we still get 4-5 bot created spam accounts per day. We're currently considering implementing QuestyCaptcha with "trick questions" that change regularly, so that bots just cannot answer them, and hopefully humans can. I'll let you know how that works out...

What proved to be very effective is indeed QuestyCAPTCHA. Reduced spam by 99 %. This happened not on just one wiki. The good thing is that the questions may be as simple as it may possibly get. My recommendation of the day. :)

It's quite possible that having something that isn't already on every other wiki, blog and forum is an advantage regardless of the robustness of the underlying CAPTCHA. That's the only explanation I can see for actually having worse results with ReCAPTCHA (some spam still gets past, plus I get user complaints from wikis in languages for which ReCAPTCHA has no books natively) than the much weaker VisualMathCaptcha (which almost no one uses, so it hasn't been targeted by spammers).

Certainly there is a need for an expiry time on any challenge issued (to make it more difficult for a spammer to take a CAPTCHA from your site, re-use it on one of their own sites and trick that site's users into solving it) and a need to block IP's after a maximum number of failed attempts (as anything with a finite number of possible correct responses otherwise invites brute-force attacks with random answers).

As for using AbuseFilter to count failed attempts? Oddly, it looks like it only keeps count of the number of times its own rules have detected something questionable - which can be used to block or demote on repeated failures - but it does not even hook into LoginAuthenticateAudit to detect that an IP is repeatedly attempting to log in with the wrong password. It also has no means to detect a user or IP is doing something to repeatedly trigger other extensions, such as ConfirmEdit or SpamBlacklist, or is repeatedly submitting payload URL's blacklisted by one or another RBL (which SpamBlacklist could be modified to detect, per its docs).

There is no AbuseFilter rule to say an IP repeatedly tripping LoginAuthenticateAudit or an extension's hooks (EditFilter, EditFilterMerged, APIEditBeforeSave, AbortMove, ArticleDelete, AbortLogin, AbortNewAccount, UploadVerification) should receive any extra penalty at all. All but one of the extensions which monitor LoginAuthenticateAudit notifications are CAPTCHAs which are programmed to appear on login if a previous login attempt failed. The Fail2banlog extension is the only here to say "too many failed attempts, goodbye" to *anything* and that only catches failed logins, not brute-force attempts to get past CAPTCHA or submit blacklisted URL's as payload. AbuseFilter does nothing about repeated violation of anything but its own rules.

To extend LoginAuthenticateAudit to report to an extension that an attempt to edit, move, upload or register an account had been repeatedly rejected by another extension would be a change to core MediaWiki code. Even then, a corresponding change to AbuseFilter would be required to get that extension to count failed attempts and ban the offending IP address or demote a user.

Failing that, CAPTCHA extensions like ConfirmEdit are going to have to use memcached or whatever storage mechanism is available to keep track of repeated authentication failures internally and impose per-IP address limits at some point. The absence of this functionality in any form is a bug which will reduce the effectiveness of CAPTCHA as a spam filter.

Certainly there is a need for an expiry time on any challenge issued (to make it more difficult for a spammer to take a CAPTCHA from your site, re-use it on one of their own sites and trick that site's users into solving it)

That doesn't avoid such case.

May make the TODOs on QuestyCaptcha even more important:

• allow maintenance of Q&A from the wiki itself. This could ensure that for example sysops can regularly update the Q&A in case a spam bot does get through
• stats on succes/fail for questions and answers to allow fine tuning.

Another idea would be to make selecting Q&As from the pool of existing Q&As possible so that e.g. every week or so a different selection gets presented. Thus more dynamic variation would be possible without having to invent heaps of new Q&As or to remove them.

I believe people will love the coder who makes these enhancements possible. :)

To be fair, these are relatively easy. They do need their own table, because you want the Q&A to be private; once that's there, keeping stats isn't hard either.

I guess this is worth an bug report for an enhancement, so this ideas do not get lost?

Sure.

Done with bugzilla:34911. You may want to vote on it. Thumbs up for its implementation.

I've added bugzilla:34913 (AbuseFilter should monitor LoginAuthenticateAudit and allow creation of rules to block IPs with multiple failed attempts) and bugzilla:34914 (proposing the functionality of LoginAuthenticateAudit be extended to also report edit, login, register, move, upload attempts being rejected by other extension hooks instead of just failed login attempts detected by core code).

Not sure if this is the best approach... perhaps simply requesting a maximum number of retries in ConfirmEdit itself then locking the IP out would be quicker?

Nonetheless, a user being repeatedly locked out for any reason (bad password, failed ConfirmEdit, failed some other spam check) is something that an AbuseFilter really ought to be able to detect, but currently cannot as only its built-in checks can be used as the basis for a rule or a limit.

I disabled editing for anons and on account registration you have to identify persons which only my target group knows (famous enough to be known by scene newbies and option to load another random pic tho). Keeps out all bots and human spammers in the first place.

I know it's super drastic but I can live with it and am more than happy with the result. Still anons can leave comments (which are spam-protected by other ways tho). May be an oppertunity for other "fan wikis".

I think most of us know that works, but it's a barrier that most of us don't want to put in place. Extension:ConfirmAccount is also possible.