How EU CAPTCHA works

Two components provide the protection: the widget, which runs in a hidden iframe on the protected page, and the verification API of EU CAPTCHA. The verification runs in the background and requires no input from the visitors.

Components

Myra EU CAPTCHA consists of the following components:

Component	Address	Task
Dashboard	`https://app.eu-captcha.eu`	Manages the account, sitekeys, permissions and statistics.
Widget	`https://cdn.eu-captcha.eu/verify.js`	Runs the verification in the user's browser and creates the token.
Verification API	`https://api.eu-captcha.eu/v1`	Verifies the token on the server.
Documentation	`https://docs.eu-captcha.eu`	Contains this manual.

The protected page loads the widget from the CDN and speaks to the verification API. If your website sends a Content Security Policy, then it must permit the two addresses. See Content Security Policy.

How a verification runs

A verification runs in the following steps:

The protected page loads verify.js from the CDN.
verify.js creates a hidden iframe and loads check.html into it.
check.html loads check.all.js. This script performs the actual verification.
The iframe reports the created token back to verify.js.
verify.js writes the token into a hidden input field named eu-captcha-response.
When the form is submitted, the token reaches your own server.
Your own server verifies the token through the endpoint POST /verify of the verification API.

Attention

The verification in the browser alone gives no protection. Only the server-side verification of the token decides whether a request is accepted or rejected. See Embedding the widget.

Risk assessment

verify.js collects the fingerprint when the page loads, thus in the protected page itself and not in the iframe. The iframe requests the result and receives it in a message. The visitors are not involved in this.

The collection runs in two stages. First, the quick probes run. Their result is available after some hundred milliseconds. The slow probes then continue in the background and stop after approximately two seconds. If the iframe requests the fingerprint before the second stage is complete, it receives the intermediate result of the first stage.

The following groups of signals go into the assessment:

Signal group	Examples
Hardware	Screen geometry, processor cores and memory, WebGL and WebGPU, audio
Rendering	Canvas drawing, font metrics and text rectangles
Browser	Time zone, storage, extensions, plugins and media queries
Network	Timings, frame rate and addresses from WebRTC
Automation	Characteristics of remote-controlled browsers, falsified data and different permissions
Behaviour	Mouse movement, scrolling behaviour and interactions
Sensors	Available input devices and the device type that follows from them

From these signals, the service calculates a risk score between 0.0 and 1.0.

Note

The service does not output the reasons for a block through the API. A disclosed detection logic would allow attackers to circumvent the protection in a targeted way. See The cause of a block is not visible.

Language of the display

During the verification, the widget shows a short text, in English for example Verifying Captcha... and Completed. The text is available in more than one hundred languages.

The widget selects the language itself. It examines the language settings of the browser in sequence and takes the first one for which a translation is available. If it finds none, it shows the text in English. The error text exists in English and German only; in all other languages, it appears in English. There is no setting on the sitekey and no attribute on the widget element for this.

Challenge and proof of work

The risk score determines the difficulty of the challenge: the higher the risk, the more elaborate the computation. The service knows eight levels of difficulty:

Difficulty	Computing effort	Applies to
0	around 600 milliseconds	Standard case for human visitors. The verification stays unnoticed.
1 to 6	rising	Suspicious signals raise the effort step by step.
7	around 30 minutes	Traffic with a very high risk.

The computation is a proof of work. Together with the task, the browser receives a minimum number of computations and a target value. In the iframe of the widget, it first performs the required minimum number of computations and then tries values until a result is below the target value. The difficulty determines the minimum number. The algorithm used is Argon2id. It is memory-intensive and therefore resistant to attacks through graphics cards and botnets.

The widget reports the solution to the verification API:

■ If the API answers with wait, the delay of the sitekey since the challenge was issued has not yet passed. The widget reports the same solution again after one second, at most 30 times.
■ If the API answers with success, the challenge is passed and the widget receives the signed token.
■ If the API rejects the solution, the widget requests a new challenge, at most three times.

When the repetitions are exhausted, the widget shows the text Verification failed, in German Überprüfung fehlgeschlagen.

Note

A high risk score does not lead to a rejection but to a longer computation. An unusually long duration indicates traffic with a high risk. See A challenge takes an unusually long time.

Note

The initial value that you set for each sitekey contains the levels 0 to 3. The risk detection sets the higher levels itself. See Configuring a sitekey.

Verification modes

The point in time at which the verification starts is adjustable. The following modes are available:

Mode	Point in time of the verification	Use
Solved Immediate (default)	The verification starts as soon as the page is loaded.	Best user experience: the verification is already complete when the users submit the form.
Solved Triggered	The verification only starts once the users touch the form.	Pages with many calls but few submissions, for example checkout or ticket pages.

The mode affects the consumption: in the Solved Immediate mode, every page call with a form counts as an assessment; in the Solved Triggered mode, only the submissions actually begun.

You change the mode in the settings of your own application, that is, where the widget is embedded. The Sitekey - [Domain] view contains no setting for it.

An assessment counts as soon as the widget begins the verification in the background. The verification in the background and the corresponding server-side verification together count as one assessment, regardless of the selected mode.