Funktionsweise

Zwei Bestandteile erbringen den Schutz: das Widget, das in einem versteckten Iframe auf der geschützten Seite läuft, und die Verifikations-API des EU CAPTCHAs. Die Prüfung läuft im Hintergrund und verlangt von den Besuchenden keine Eingabe.

Bestandteile

Myra EU CAPTCHA besteht aus den folgenden Komponenten:

Komponente	Adresse	Aufgabe
Dashboard	https://app.eu-captcha.eu	Verwaltet Konto, Sitekeys, Berechtigungen und Statistiken.
Widget	https://cdn.eu-captcha.eu/verify.js	Führt die Prüfung im Browser der Nutzenden aus und erzeugt den Token.
Verifikations-API	https://api.eu-captcha.eu/v1	Prüft den Token serverseitig.
Dokumentation	https://docs.eu-captcha.eu	Enthält dieses Handbuch.

Die geschützte Seite lädt das Widget aus dem CDN und spricht die Verifikations-API an. Wenn Ihre Website eine Content Security Policy sendet, dann muss diese beide Adressen freigeben. Siehe Content Security Policy.

Ablauf einer Prüfung

Eine Prüfung läuft in den folgenden Schritten ab:

1. Die geschützte Seite lädt verify.js vom CDN.
2. verify.js erzeugt ein verstecktes Iframe und lädt darin check.html.
3. check.html lädt check.all.js. Dieses Skript führt die eigentliche Prüfung aus.
4. Das Iframe meldet den erzeugten Token an verify.js zurück.
5. verify.js schreibt den Token in ein verstecktes Eingabefeld mit dem Namen eu-captcha-response.
6. Beim Absenden des Formulars gelangt der Token an den eigenen Server.
7. Der eigene Server prüft den Token über den Endpunkt POST /verify der Verifikations-API.

Warning

Die Prüfung im Browser allein schützt nicht. Erst die serverseitige Prüfung des Tokens entscheidet über Annahme oder Ablehnung einer Anfrage. Siehe Widget einbinden.

Risikobewertung

Das versteckte Iframe erhebt beim Laden der Seite einen Fingerabdruck aus dutzenden Signalen des Browsers. Die Besuchenden sind daran nicht beteiligt. Die folgenden Gruppen von Signalen fließen in die Bewertung ein:

Signalgruppe	Beispiele
Hardware	Merkmale des Geräts und die Geometrie des Bildschirms
Rendering	Darstellung über WebGL und Audio
Verhalten	Mausbewegung, Scrollverhalten und Interaktionen
Netzwerk	Merkmale der Verbindung und der Herkunft der Anfrage

Aus diesen Signalen berechnet der Dienst einen Risikowert zwischen 0.0 und 1.0.

Note

Die Gründe für eine Blockierung gibt der Dienst nicht über die API aus. Eine offengelegte Erkennungslogik würde es Angreifenden erlauben, den Schutz gezielt zu umgehen. Siehe Grund für eine Blockierung nicht sichtbar.

Challenge und Proof-of-Work

Der Risikowert bestimmt den Schwierigkeitsgrad der Challenge: Je höher das Risiko, desto aufwendiger die Rechenaufgabe. Der Dienst kennt acht Schwierigkeitsgrade:

Schwierigkeitsgrad	Rechenaufwand	Trifft zu auf
0	rund 600 Millisekunden	Regelfall bei menschlichen Besuchenden. Die Prüfung bleibt unbemerkt.
1 bis 6	ansteigend	Auffällige Signale erhöhen den Aufwand schrittweise.
7	rund 30 Minuten	Verkehr mit sehr hohem Risiko.

Die Rechenaufgabe ist ein Proof-of-Work. Der Browser erhält zusammen mit der Aufgabe einen Zielwert und probiert in einem Hintergrund-Thread so lange Werte durch, bis das Ergebnis den Zielwert erreicht. Als Verfahren dient Argon2id. Es ist speicherintensiv und dadurch gegen Angriffe über Grafikkarten und Botnetze widerstandsfähig.

Das Widget meldet die Lösung an die Verifikations-API:

• ■ Antwortet die API mit wait, rechnet der Browser weiter.
• ■ Antwortet die API mit success, ist die Challenge bestanden und das Widget erhält den signierten Token.

Note

Eine fehlgeschlagene Challenge kennt der Dienst nicht. Eine Challenge wird entweder gelöst oder sie dauert länger. Eine ungewöhnlich lange Dauer weist auf Verkehr mit hohem Risiko hin. Siehe Challenge dauert ungewöhnlich lange.

Note

Der Anfangswert, den Sie je Sitekey einstellen, umfasst die Stufen 0 bis 3. Die höheren Stufen vergibt die Risikoerkennung selbst. Siehe Sitekey konfigurieren.

Prüfmodi

Der Zeitpunkt, zu dem die Prüfung startet, ist einstellbar. Die folgenden Modi stehen zur Verfügung:

Modus	Zeitpunkt der Prüfung	Einsatz
Solved Immediate (Standard)	Die Prüfung startet, sobald die Seite geladen wird.	Bestes Nutzererlebnis: Die Prüfung ist bereits abgeschlossen, wenn die Nutzenden das Formular absenden.
Solved Triggered	Die Prüfung startet erst, wenn die Nutzenden das Formular berühren.	Seiten mit vielen Aufrufen, aber wenigen Absendungen, zum Beispiel Checkout- oder Ticketseiten.

Der Modus wirkt sich auf den Verbrauch aus: Im Modus Solved Immediate zählt jeder Seitenaufruf mit Formular als Assessment, im Modus Solved Triggered nur die tatsächlich begonnenen Absendungen.

Den Modus stellen Sie in den Einstellungen Ihrer eigenen Anwendung um, also dort, wo das Widget eingebunden ist. Die Ansicht Sitekey - [Domain] enthält dafür keine Einstellung.

Ein Assessment zählt, sobald das Widget die Prüfung im Hintergrund beginnt. Die Prüfung im Hintergrund und die zugehörige serverseitige Verifikation zählen zusammen als ein Assessment, unabhängig vom gewählten Modus.