This is why I still recommend using other form spam prevention techniques before sacrificing usability for a CAPTCHA. One of the most effective combinations for 80%+ of the sites I've ever dealt with is having a honeypot field in the form, plus some amount of time required to pass before the form can be submitted successfully. There are other ways to mitigate bots as well, but these two alone have sufficed for quite some time for anything but dedicated human-based attacks.
Granted, I think the checkbox CAPTCHA is much better than the UX disaster that is the 'type some hard-to-read letters' CAPTCHA, but it's still adding a burden on the user, rather than a burden on the bot.
(Source: I maintain the Drupal Honeypot module[1], and have used it in a ton of different situations where CAPTCHA/reCAPTCHAs would normally be recommended).
The weird thing about this entire No Captcha solution, in my opinion, is that it assumes that a captcha is the most efficient method for defeating spam.
In most blackhat circles, captchas are an afterthought. You figure out everything else (IPs, original content), then plug in a service like deathbycaptcha that solves the captcha for... looks like $1.39 per 1000 (thanks to ultramancool for the correction). (http://deathbycaptcha.com). What nocaptcha does is only show that captcha (which is already defeated), to a certain subset of the users who haven't been deemed trustworthy. So, the big bot builders will take a day or two and beat the system, and we're right back to where we started.
Honeypots, however, are brutal - especially if you throw a couple in there. When building a bot you build it for efficiency. If your site does anything abnormal (whether it's 'what's n+n?' or 'what popular figure comes through your chimney in December?') a bot is hopeless.
That being said, however, a bot is only hopeless so long as a solution isn't implemented widely enough to be worth breaking through for spammers. If, for example, Wordpress came up with 1000 questions like that, someone somewhere would come up with and sell 1000 solutions.
In some sense it may be the case that Google is one of the worst companies to create a a simple anti-spam API. I'm sure there's something they could do that would be more effective than this, but this won't really move the needle.
Just a small correction, it's $1.39 per 1000. Some competing services are as low as $1 per 1000.
> If your site does anything abnormal (whether it's 'what's n+n?' or 'what popular figure comes through your chimney in December?') a bot is hopeless.
Check out https://github.com/kbhomes/TextCaptchaBreaker for a great example of how trivial these are to break. And free too. Not to mention you could convert them to an image and feed them to a site like deathbycaptcha, antigate, etc. I've tried feeding some fun stuff like this through these services, you get interesting results and will likely have a high failure rate, but you'll get enough right to pass around 50-70% of the time.
Honeypot fields are pointless as a good bot just rips the whole form and fills in what it wants, if needed, executes JS too.
Of course, I'm assuming a determined attacker going after your individual site, not a bot just spamming random web forms. So it really depends on your threat model.
> If your site does anything abnormal (whether it's 'what's n+n?' or 'what popular figure comes through your chimney in December?') a bot is hopeless.
I run a forum using Invision Power Boards, which has a built in question-and-answer verification during registration. Soon after I set it up I watched a bot in the server logs completing the registration in only a couple seconds.
I suspect that because IPB is a big enough target, they farm out the questions just like they farm out CAPTCHAs, and build a database of questions and answers. You'd need to include some randomness in the questions to throw them off.
With both of your examples (and many others I've come across) those question type captchas can be done with a quick ping to Google and a sanity check on the answer
"what popular figure comes through your chimney in December" -> "Santa Claus - Wikipedia, the free encyclopedia"
"what's 1+1" -> "2"
They only really work if maybe the question is in the market of the site you're registering for "What's <some popular guy on site>'s last name" etc
~$1.30 for 100 capachas, $50 for 10000 google searches per day, along with other search engines filling the same role.
probably the most damning thing is they are questions and answers from a database, unless you bother to make your DB unique (so no using openly available Q/A databases), everyone is going to have access to the right answers.
also, similar to paying people to answer capachas, you can pay people to answer questions
A custom spam prevention system, such as a honeypot or the simple "What's n+m?" field, works at 100% until your site is valuable enough for the attacker to spend a couple of cycles to circumvent the honeypot - then it drops to 0%. Publishing your solution as a module just serves to increase the value of circumventing it.
The value of "real" CAPTCHAs is that they retain their deterrence no matter how much effort the attacker invests.
The logic is sound, but doesn't play out in the real world that often. The reality is, the overwhelming majority of form spam comes from scripts and bots that are not that well-targeted, and in most cases, people who would normally install reCAPTCHA have no need for it.
Additionally, even though the module has been published for quite a while, and honeypot/time-gate techniques are fairly common, most bots can't account for the small adjustments that are made from site to site using adjustable settings for the module (like field name, time defaults, etc.).
The truth is: once your site or app is targeted by a human who is determined to spam you, the stakes are raised to the point where neither CAPTCHAs nor standard honeypots will deter everything. You will have to do at least some ongoing work to find a way to defeat the spammers.
>The logic is sound, but doesn't play out in the real world that often.
It does play out in the real world a whole lot if you have the misfortune to be in charge of certain kinds of websites.
> once your site or app is targeted by a human who is determined to spam you, the stakes are raised to the point where neither CAPTCHAs nor standard honeypots will deter everything.
reCAPTCHA stops the bulk of it. Yes, people can still use CAPTCHA farms, but at the very least they increase the attacker's cost and will generally reduce their spam rate by a lot. After 4chan rolled out reCAPTCHA, 5+ years of spam problems vanished in an instant.
> It does play out in the real world a whole lot if you have the misfortune to be in charge of certain kinds of websites.
Very true; for some classes of sites, this is definitely the case. I was speaking more in a general sense, as I see many developers and project teams install some sort of CAPTCHA on every site as a default. In most circumstances, I think people should go for the simpler solution first, then be ready to drop in something like reCAPTCHA (or some other active spam deterrent) only when spam becomes a real problem.
I'd agree with that. It's good to have the code production-ready at a moment's notice though, because the reaction time can sometimes mean the difference between having to clean up 100 spam submissions and thousands of spam submissions.
We use the Drupal Honeypot module on PortableApps.com and it works well. Mainly to block spammers from flooding comments and forum posts with bots. As one of the world's largest Drupal sites, we're under constant attack. We still use captchas for user registration, though, as we have a ton of accounts created by humans and then posted to by bots, which seems to be the m.o. of some of the larger spammers now.
The problem is, when you have a high value payoff for breaking in, then manual methods and people running manual scams becomes reasonable. I work for a classic car website, and the majority of our issues comes from real people, running real scams.
We have a lot of detection and followup in place, with a manual review process. The next generation will add the need for the user being logged in (though a click-through social network login will make it easier for most users)... At least in that case it's easier to tell when someone has a twitter account with no follows/followers who's never tweeted. Nothing is perfect though.
It really is an arms race, my point is the rules are very different depending on your market.
I created all sorts of honeypots (time based, hidden fields) and they quickly became worthless. As soon as the Russian bot networks target you, honeypots won't do anything to stop them.
Captcha has been the only thing that actually works. I will never use honeypots ever again. The headaches caused by those Friday night attacks aren't worth it.
This would mainly only work against scrapers, tho, and not so much for account creation.
My argument is that Google could have done better to offer a completely different solution (e.g. some sort of proxy service) than to add a (apparently fallible) whitelist to recaptcha.
Granted, I think the checkbox CAPTCHA is much better than the UX disaster that is the 'type some hard-to-read letters' CAPTCHA, but it's still adding a burden on the user, rather than a burden on the bot.
(Source: I maintain the Drupal Honeypot module[1], and have used it in a ton of different situations where CAPTCHA/reCAPTCHAs would normally be recommended).
[1] https://www.drupal.org/project/honeypot