How to Bypass “Slider Captcha” | Hacker News Reader

How to Bypass “Slider Captcha”

medium.com

91 pointsjsnell42 comments

Looking at the source code for at least the first example [0] it looks like a simple $('form').submit() would work just as well. It's all the library is doing internally (after some HTML5 form validation checks)

I suspect most slider captcha's out there are doing something similar or at the very most setting a hidden field to "true" or "1" etc. Very few are probably fingerprinting your mouse/touch movements to actually validate you're a real human being.

[0] https://github.com/kthornbloom/slide-to-submit/blob/master/j...

I was wondering this. Surely a captcha needs to have some form of 'hidden knowledge' that is validated only by sending something to the server for it to check - like the jigsaw puzzle captcha at the end of the article, or a 'pick the images containing a bus' kind of thing. With the slider, there doesn't appear to be anything stopping a bot client from just submitting a form and pretending that it interacted with some HTML and javascript.

It's just not popular enough to be handled by bot scripts (yet)... and most of spam bots are not targeting one particular site so this worked for a while, just like math captcha and drag-an-image worked for a while. The moment they get popular enough for bot authors to tackle the issue, they'll stop working.

The sliders you generally see in the US tend to be just setting a field to true or 1.

The sliders in China are doing more than the same amount of fingerprinting if not more than recaptcha, port scan your local device from your browser, and other fun things. Alibaba's sets a dozen cookies prefixed with big_brother, which I find amusing.

They will let you slide once or twice, then challenge you with an actual captcha if you fail heuristics. Blocking fingerprinting scripts will result in outright failure to sign in, or being challenged with a full captcha every attempt. They also generally do not give a crap about accessibility.

The way I see it, Captchas are an approach to fend off _untargeted_ spam bots. If someone specifically targets your website and tailors his spam bot accordingly, then you have a problem, but that is not inherent to Slider Captchas.

On the other hand, a Slider is much more user friendly than a scrambled image or having to select all pictures with light bulbs.

So I think this article misses the point a bit...

Exactly. To avoid contact form spam I added a simple "Fill in this number (123):" to on of our forms. The number is even hardcoded! But that was enough to reduce contact form spam from ~10-20 a day to zero.

I am one of the admins on a forum for an open-source video game. We have two extremely easy questions required on signup (one asks for part of the domain name of the site, the other is a trivially googleable game fact) purely to stop untargeted spam attacks and it is remarkably effective. Of course some spammers get through, but that's why we have moderators.

This slider doesn't appear to improve upon reCaptcha's poor accessibility story, as there's no reference to what a blind user or a user without a mouse is supposed to do to interact with this element.

Why would it? None of these demographics would be able to interact with online advertising either, and that's what today's web is all about.

There's def ads for blind people.

Wouldn't deaf ads be for deaf people?

Not sure if you're making a joke but I definitely misread def (definitely) as deaf

All these sliders can be automated with the UI.Vision browser extension and its visual XMove command: https://ui.vision/docs/xclick#xmove

The target audience are web testers. The advantage of this approach is that it requires no Javascript knowledge, as you automate the task visually. It is similar to the well-known Sikuli tool, but works inside the browser.

The "drawback" of this image-recognition driven approach is that it is much too slow for spamming... which is actually another advantage from my point of view.

It's disappointing that so many websites drop trust and human moderation in favor of half-baked solutions that disregard the disabled. I've found forms where I could remove the disabled attribute from a submit button and bypass captchas entirely, I have no faith in them any more.

Human moderation is not a practical suggestion when literally 99% of submissions would be bots.

Or for small websites run by a single person.

As mentioned by other comments, we will likely end up in an arms race of adversarial neural networks. Which will be opposed by neural nets driven by manual classification of spam/not spam entries. However, I think the spammers have a decisive advantage. What you are dealing with here is an asymmetric situation: while sites must spend money on people to do classification, the spammers have an oracle against which their neural nets can verify responses. This means improving their bots to fight new anti-spam tech is easier. I can't say what the solution is here.

The asymmetries cut both ways. The site can detect probing attempts, and if that happens switch into a mode where the captcha results are obfuscated. Let's use blog comments as an example:

The normal mode of operation is to give the user a clear error message if they failed the captcha, and have the post go through if they passed the captcha.

If the number of failures is higher than e.g. 10 in the last hour, successful captchas cause the comment to be put in a hold queue for an hour. Failed captchas cause the comment to be rejected. The attacker can't know if they passed the captcha until an hour has passed, which slows down their iteration a lot.

You can then slow it down further with some randomization, while keeping the experience of real users the same. E.g. successful captchas go to the hold queue. Failed captchas are rejected 99% of time time. The remaining 1% of the time they go to the hold queue, but are auto-deleted after a random delay of 2h-12h.

So you accept a small amount of temporarily visible spam as the price of obfuscating the signals.

> The attacker can't know if they passed the captcha until an hour has passed.

Naah. The attacker just does batch learning: dump a ton of comments, wait an hour, spend a few minutes training, rinse-and-repeat. Your users also won't tolerate tons of delays.

> You can then slow it down further with some randomization.

So now I wait a few extra hours, and have 99% accurate data. That's still pretty good, honestly. Ideally, a neural network can get a good model from less accurate data than 99%; just tweak the learning rate or use sgd, modify mini-batch size, etc.

The advantage of the site, of course, is that legitimate businesses are likely more able to afford people with this sort of knowledge. The scammers are probably script kiddies who clone a template and tweak a config; they'd have real jobs if they knew more.

I like the idea of a puzzle slider captcha. It is funny enough and quite different from usual captcha out there

Solving a puzzle would be much more fun than identifying street lights and then waiting 20 seconds for Google's RECAPTCHA to "check" the result. Unfortunately both of these things can be easily broken with bots. The data Google tracks/checks is what's difficult for bots.

Solving a puzzle would be much more fun than identifying street lights

But that wouldn't give Google free data annotations.

It would be nice if we could get back to those good old days when doing a reCaptcha helped digitize books.

How did that work if the purpose of answering a captcha is matching with a known answer. If you were helping solve then it would imply you would get a few that didn't pass you through the gate even if you answered correctly.

Those used to have two words. One known and one not. To purposely fuck the system you’d have to guess which is the unknown word.

Two challenges. One where the system has high confidence on what the correct label is, one where it has low confidence.

There are already companies out there doing 'biometric' analysis of user sessions to discern between authentic, fraudulent and automated sessions, and they're already being applied to things such as loss prevention in financial firms.

I had always assumed that this sort of analysis was already done on the 'slider captchas'. It wouldn't surprise me if this becomes a thing.

Humans are almost never going hit the exact centre of the box, and unless the browser does some smoothing I suspect they never swipe smoothly and horizontally.

Then bot makers will start applying fuzzing to the movements, randomly placing the cursor inside a region over the target, varying the speed, releasing the slider and trying again, etc.

There's no reason yet to go to such lenghts, so the extra effort would be wasted, but as soon as it becomes necessary, someone will do it.

The endgame is probably training some neural net with real user behavior and using that to generate realistic usage patterns.

Then the spammers using that data to create more bots.

Much cheaper to just hire poor people to click boxes.

Even the bot in this blog does fuzzing

Trained human is likely capable of doing it exactly like the Puppeteer does minus the fact that the pointer may move instantly in case of the machine doing it. One wrong assumption covered, two more to go.

The second assumption made here is that the (as pointed out) fuzzing is a thing.

The third one is that you can't be sure of the input device. Joystick like the one seen on ThinkPad is uncommon but still used as the input device. Touchscreens are common but human-ish, though you will have to cover them too. The extreme case is that some X-savvy person may just move the pointer sometimes using the X's built-in capabilities, by dmenu and stuff, and even if that's highly unlikely, it still will fail.

There's no point in doing all the possible checks you may come up with: egde cases, no matter how impossible they look, still exist and break the consistency of the slider solution easily. Google captcha and Funcaptcha are nearly the best options you can readily get, freeing your hands and head of a huge deal of hassle you will face when dealing with this task.

That's a great writeup. I wonder if there is some further server-side validation going on. It doesn't seem like the author actually submitted the forms - there could be further checks.

Can anyone recommend a minimally invasive, accessible capture mechanism that would perhaps still cut out X% of non-targeted bot spam for some possibly small but nonzero X?

I do not want to expose users to recaptcha 3 TOS or any other opt in monitoring.

I was considering some form of completely unanalysed input such as non standard element based checkbox as a low pass filter.

You may want to consider running some proof-of-work in the browser, that would be costly to run for bots.

That's not a bad idea.

I'd be concerned about being accused of/blocked for crypto-jacking. That said, I'd like to see a proof-of-work based captcha that donates any earnings to charity as cryptocurrency.

I came across hashcash.io before, previous discussion: https://news.ycombinator.com/item?id=7944540

Alternatively I could write something dead simple from scratch that looks for sha collisions to burn a few cycles. Would this be less dubious?

All that does is further penalize the victims of botnets by driving up their electricity bills. It won't hurt the spammers who run the botnets.

This is only true if we assume that spammers are not already saturating the resources of their victims. And even then, it's better than penalizing blind or deaf people.

Can't remember where I saw this, but someone else talked about creating a field in the form, hidden by CSS, that if filled in would just discard that submission. Should work for most automated bots that aren't specifically targeting you.

This is known as the honeypot technique, it's quite old and I'd say that most spam bots go defeat it easily enough already.

<pflenker>’s top level post makes a good point here, suggesting that because untargeted bots are your biggest concern, even the simplest custom challenges tend to work quite well (e.g. “enter the number 123 in the last box”) — with ”custom” being the key here!

Because: Until large strides are made in artificial general intelligence [1], simple little challenges that are creatively designed will be very difficult for a single general-purpose AI system to crack 100% automatically.

In contrast, if your site is targeted with actual human engineers trying to crack your anti-bot system, there’s a good chance they’ll succeed no matter how strong your system [2]. In the case of such targeted attacks, presumably your company will be so important and successful that you’ll be able to afford similarly expensive resources to defend from such attacks.

[1] Don’t get me wrong, I’m not doubting that sufficiently general AI is coming that can easily solve such challenges. But for now, to get your startup off the ground, this is apparently an effective short term solution that is very easy to implement.

[2] Human-operated “sign up farms” are definitely a thing, in addition to actual human-operated spam / advertising / propaganda farms (imagine a typical “call center”-style office hired to do this).

Reply on news.ycombinator.com