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:

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

Warning

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

When the page loads, the hidden iframe collects a fingerprint from dozens of browser signals. The visitors are not involved in this. The following groups of signals go into the assessment:

Signal group	Examples
Hardware	Characteristics of the device and the geometry of the screen
Rendering	Display through WebGL and audio
Behaviour	Mouse movement, scrolling behaviour and interactions
Network	Characteristics of the connection and of the origin of the request

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.

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 target value and, in a background thread, tries values until the result reaches the target value. 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 browser continues to compute.
• ■ If the API answers with success, the challenge is passed and the widget receives the signed token.

Note

The service knows no failed challenge. A challenge is either solved or it takes longer. 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.