The No CAPTCHA problem
homakov.blogspot.com
homakov.blogspot.com
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).
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.
> 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.
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.
"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
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
The value of "real" CAPTCHAs is that they retain their deterrence no matter how much effort the attacker invests.
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.
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.
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.
This doesn't always mean it's worth it, but it's a good leverage for beginners.
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.
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.
Another alternative that comes to mind (albeit much more complicated) is link encryption ala SpikeStrip: http://www.cs.ucsb.edu/~ravenben/publications/pdf/spikestrip...
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.
If we take reputation, IP and cookie. All must be in order to pass. We want to spam a 1000 forms today. Scenario 1: The clickfarm itself fills in the Captcha. Result: Their IP's will soon be blacklisted, reputation of a third-world account will be inherently low. Scenario 2: We let the clickfarm send the answer to our own bot, which selects the right pictures. Result: Google will see a single IP and cookie trying out 1000s of captcha's a day, and ban you. Scenario 3: We let the clickfarm send the answer to our own bot, this bot uses a list of proxies that haven't yet been banned. Result: Google will see a single account cookie trying out 1000s of captcha's a day, from different IP's and ban you.
Can anyone come up with a scenario which involves reputation, IP and cookie that does not end up with Google detecting and banning your efforts? Cookie swapping?
Now his IP is blacklisted, because there are lots of people using the same exit node; his reputation is low for the same reason, and the cookie is rejected. There's a good chance that this one person will be blocked, even though he didn't do anything wrong.
For a simpler case, private browser sessions over a VPN would suffer from the same issue.
I'm often being denied access to free content because I'm accessing from the "wrong" countries, and that's infuriating. If I start being locked out of free content due to my privacy measures, I'm probably going to start setting buildings on fire.
But while I believe content creators should be able to control access, I think it's ridiculous to ban certain countries from access to certain content -- I don't quite see the point.
And also, being "owed" free content != being able to access free content you otherwise would be able to access were it not for a service like TOR or a VPN (e.g. escaping the Chinese firewall using a VPN service whose IP is banned from a website versus wanting to watch a movie but living in Germany instead of the U.S.)
As soon as you have valid g-recaptcha response you don't need to persist any cookies - use it outright.
Google could have made it so much easier and more secure: a POST request to google.com/verify_me will have Origin header in it to prevent CSRF (only wordpress.com scripts will be able to get token). Also there would be no need to make a click. No CAPTCHA looks fancy but the real No CAPTCHA should always have visibility:none!
I agree, but I suppose they want something that's a Placeholder, if the user needs to type a captcha
Is the whole point of this to encourage hackers to get working on this AI challenge of identifying similar photos?
Either they need to hire a lot of people to sit around making these sets or they have an automated way of creating these sets which can be reversed. It would seem to be an arms race where google is paying people, but attackers can have people break it at a cost less than creating them (takes less time to match them up then to find good photos, clean them up, tag them, etc.).
An attacker would also just target the database where this is all stored. With the text recaptcha, it would seem that they have all of these photos and scanned books and you have 8+ character strings of [a-zA-Z0-9], random guessing would not be good enough, so the attacker needed to solve the OCR problem.
However, given the option to select x of 9 images, if you assume that the extremes are less likely of 1/9, 2/9, 8/9, 9/9- then I can hope to get lucky picking 4 or 5 each time, the order does not matter. If you distribute the attack to get around rate limits, etc. - perhaps just picking the first through fifth images gives you a sufficiently high success rate.
[1] http://www.google.com/recaptcha/intro/#creation-of-value
Probably sums it up best.
Q//But google now is better at recognizing those numbers.... A//Right... that's why they now request the next "way to expensive" to implement "free" service from you, your recognition... and association capabilities.
O_O
judging by the comment you wrote right after that, I would assume you are one of the people who likes not to think.
They are making people click checkboxes and deviating from the old model of recognition. Your comment makes no sense.
If they have to make very careful sets of photos to avoid confusion, then the sets of photos will be small enough to build lookup libraries for bots.
Why don't they just invalidate the current challenge when a new one is requested? :S
>$url = 'https://hashcash.io/api/checkwork/' . $_REQUEST['hashcashid'] . '?apikey=[YOUR-PRIVATE-KEY]';
hashcashid can change URL completely to something like ../../newpath?newparams#
http://www.9lessons.info/2014/12/google-new-recaptcha-using-...
Upvote FTW.
Secondly, If you tell me that one dude [author] ruled the one+ year work of the engineering team at google as a flaw and simplified it as [So what Google is trying to sell us as a comprehensive bot detecting algorithm is simply a whitelist based on your previous online behavior, CAPTCHAs you solved.] and that you believe it, I would question your intelligence.
This is supposed to be tech savvy community at least to some degree, what the fuck.
Now, in the google's blogpost it reads [Advanced Risk Analysis backend for reCAPTCHA that actively considers a user’s entire engagement with the CAPTCHA—before, during, and after—to determine whether that user is a human.]
[However, CAPTCHAs aren't going away just yet. In cases when the risk analysis engine can't confidently predict whether a user is a human or an abusive agent, it will prompt a CAPTCHA to elicit more cues, increasing the number of security checkpoints to confirm the user is valid.]
So my guess would be they analyze users behaviour on the page where captcha is located, things like mouse movements, time it takes to type out the words, spelling mistakes corrected and whatever else humans do differently than bots - and only then combine that with your historical cookies. Maybe it is much more complicated than that, I, as well as you, don't know the details.
Do you really think that they would go ahead and implement a such system without rigorous testing of effectiveness? I am sure that they tested it extensively with users, AND with bots, and decided that it is better than the current system, and ONLY then deployed it. Rant off.
If they can track mouse movements why in incognito mode i'm not a human for them anymore? I was expecting same but from what I see it's just a whitelist. And it's OK. Problem is, which you probably didn't care to read, is it's vulnerable to simple clickjacking which opens another weakness - i can use your click on my page to get your reCAPTCHA token and feed it to my spam bot.
I'm actually happy with No CAPTCHA, because it's making progress. But it's not good enough (see the rest of comments, it could be a background AJAX request instead).
I did read it. My point is, you, or I, or anyone for that matter does not know the inner details of how it works.
>>If they can track mouse movements why in incognito mode i'm not a human for them anymore?
Maybe having a clean cookie history is not good enough during the risk assessment.
Look, my entire point is, google is not a joke company. I am certain that they tested it for effectiveness before deploying.
So what do you think about clickjacking issue? I made an assumption about their algo and maybe I'm wrong and they do track your mouse, but there's exploitable weakness. My post is 1) your algo seems simple 2) here's a bug in it.
If I do the click on your github page, I get a challenge. My clicks were never accepted as human on your github page. My clicks were always accepted as human on wordpress page.
Since you obviously don't know who Homakov is I can't take your post very seriously.
Homakov has exposed several serious security flaws at Facebook and Google before. I'm pretty sure Google is actively trying to headhunt him since he is one of the best in the web security field.
I think the gap between the marketing material for nocaptcha (a simplified website, a youtube video with animations) and the seemingly lacking actual implementation is why this blog post was relevant for me.
Like other tech people around here, I was hyped up by the "smarts" of a system that uses cursor detection etc. to silently validate that I am a human. This blog post seems to indicate that the validation is a much simpler issue of previously passed tests and the amount of data that Google has associated with the user.
That is a bold statement, something presented as a fact, not a hypothesis.