Why a captcha does not stop bots
Contents
Share
A captcha does not close an automatic visit. Yandex Direct's help describes it as a possible response to a suspicious click, and the OWASP catalog calls defeat of the test the case where the puzzle was solved — by machine reading or by a farm of people. Below is where a captcha still helps, where it breaks, and how a computation task in the browser differs from it.
If you put a captcha on a form or a login and treat the topic as closed, traffic can still reach the site. Decide in advance what the second layer checks once the test has been passed.
What a captcha does in Direct
The help describes an antifraud update for campaigns in the Yandex Advertising Network and on search. Previously the algorithm reviewed behavior after the click and removed invalid impressions, clicks, and conversions from the statistics, but it did not stop that traffic from reaching the site. Now it also lowers the risk of the visit itself: before an impression, the ad may not be shown if the system is confident it is facing a bot or a fraudster, and on a suspicious click it may show a captcha.
The help does not promise that traffic no longer reaches the site. The next paragraph says outright that fraud can still arrive. A captcha in the ad account is a possible step by the platform, not a lock on your form.
Why the test loses
The OWASP automated threats catalog (OAT-009) expands CAPTCHA as a completely automated public Turing test that tells a computer from a human. The threat is named CAPTCHA Defeat: automation tries to obtain an answer to a visual or audio test, a mini-game, or an arithmetic task. The answer can come from machine reading or from a farm of people.
In the catalog editors' preface of 15 February 2018 the earlier name Bypass was replaced with Defeat. The point of the rename is this: the puzzle is not skipped because of a crooked install, it is solved, and against a determined attacker the test itself is ineffective. The catalog does not put service names or a solving procedure into the public description, and it gives no success rates. The practical conclusion is that a passed captcha does not prove a person submitted the form.
OWASP's guidance on credential stuffing says the same thing at account login. A captcha on a login attempt helps notice automation and can slow guessing, but it is not perfect: tools and services exist that solve captchas with a noticeably high success rate. IP blocking stops simple guessing and should not be the only defense: an address is easy to change, and a distributed approach through proxies keeps the rate from one address low. Client-side checks, including JavaScript, can be forged, so OWASP requires a second layer. Program names and rate thresholds are not carried into this walkthrough. What you need is the second layer, not a list of bypasses.
How a browser task differs from a captcha
Adam Back's article of 1 August 2002 describes hashcash as a way to slow systematic abuse of unmetered resources, originally mail and anonymous remailers. The author dates the first proposal to May 1997. A cost function mints a token that is a proof of work. It should be cheap to verify and configurably expensive to compute. In the interactive variant the server gives the client a challenge. The article separates this technique from a captcha: there is no human in the loop, and the price is the amount of computation. The token formula and the number of zero bits are not carried over here, and the article does not set a difficulty for a web visit.
With Binetro, a suspicious visit can be given a computation task in the browser. A correct solution confirms the check and can change a "challenge" decision into "allow." A "block" decision is not cancelled by the task. The task cannot be offered instead of an allow. Difficulty, lifetime, and format are not published. This is not a captcha: a person does not solve a picture, and a block is not bought off with computation.
What to check on your side
Separate the platform captcha from a captcha on the site. Direct may show one on a suspicious click and still let some fraud reach the site.
Do not treat a solved test as proof of a person. OWASP describes defeat as a solved puzzle, including one solved by other people's hands.
Do not leave IP blocking as the only measure. The address changes, and an approach through proxies keeps the rate from one address low.
Add a second layer that cannot be forged by swapping JavaScript in the browser alone.
If you use a computation task instead of a picture, remember Binetro's boundary: a correct answer can change "challenge" to "allow" and does not cancel "block."
| Technique | What it does | Where it breaks |
|---|---|---|
| Captcha on a click in Direct | May appear on a suspicious click; the ad may not be shown | Fraud can still reach the site |
| Captcha on login | Notices automation and slows guessing | Tools, services, and people solve the test |
| IP blocking | Stops simple guessing | The address is changed; the rate from one address stays low |
| Computation task | Expensive to mint, cheap to check, no human in the loop | A correct answer does not cancel a block |