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:

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

Achtung

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

Den Fingerabdruck erhebt verify.js beim Laden der Seite, also in der geschützten Seite selbst und nicht im Iframe. Das Iframe fordert das Ergebnis an und erhält es über eine Nachricht. Die Besuchenden sind daran nicht beteiligt.

Die Erhebung läuft in zwei Stufen: Zuerst laufen die schnellen Prüfungen, deren Ergebnis nach wenigen hundert Millisekunden bereitsteht. Die langsamen Prüfungen laufen anschließend im Hintergrund weiter und brechen nach rund zwei Sekunden ab. Fordert das Iframe den Fingerabdruck an, bevor die zweite Stufe fertig ist, dann erhält es das Zwischenergebnis der ersten Stufe.

Die folgenden Gruppen von Signalen fließen in die Bewertung ein:

Signalgruppe	Beispiele
Hardware	Bildschirmgeometrie, Prozessorkerne und Arbeitsspeicher, WebGL und WebGPU, Audio
Rendering	Zeichnung über Canvas, Schriftmaße und Textrechtecke
Browser	Zeitzone, Speicher, Erweiterungen, Plugins und Medienabfragen
Netzwerk	Laufzeiten, Bildwiederholrate und Adressen aus WebRTC
Automatisierung	Merkmale ferngesteuerter Browser, verfälschte Angaben und abweichende Berechtigungen
Verhalten	Mausbewegung, Scrollverhalten und Interaktionen
Sensoren	Vorhandene Eingabegeräte und die daraus abgeleitete Geräteart

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

Hinweis

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.

Sprache der Anzeige

Während der Prüfung zeigt das Widget einen kurzen Text an, auf Deutsch zum Beispiel Captcha wird überprüft... und Abgeschlossen. Der Text liegt in mehr als hundert Sprachen vor.

Die Sprache wählt das Widget selbst: Es geht die Spracheinstellungen des Browsers der Reihe nach durch und nimmt die erste, für die eine Übersetzung vorliegt. Findet es keine, dann zeigt es den Text auf Englisch an. Den Fehlertext gibt es nur auf Deutsch und Englisch; in allen anderen Sprachen erscheint er auf Englisch. Eine Einstellung am Sitekey oder ein Attribut am Widget-Element gibt es dafür nicht.

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 eine Mindestzahl an Berechnungen und einen Zielwert. Im Iframe des Widgets führt er zuerst die geforderte Mindestzahl an Berechnungen aus und probiert danach so lange Werte durch, bis ein Ergebnis unter dem Zielwert liegt. Der Schwierigkeitsgrad bestimmt die Mindestzahl. 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, ist die Zeitvorgabe des Sitekeys seit der Ausgabe der Challenge noch nicht abgelaufen. Das Widget meldet dieselbe Lösung nach einer Sekunde erneut, höchstens 30-mal.
■ Antwortet die API mit success, ist die Challenge bestanden und das Widget erhält den signierten Token.
■ Lehnt die API die Lösung ab, dann fordert das Widget eine neue Challenge an, höchstens dreimal.

Sind die Wiederholungen erschöpft, dann zeigt das Widget den Text Überprüfung fehlgeschlagen an, in englischer Sprache Verification failed.

Hinweis

Eine hohe Risikobewertung führt nicht zu einer Ablehnung, sondern zu einer längeren Rechenaufgabe. Eine ungewöhnlich lange Dauer weist auf Verkehr mit hohem Risiko hin. Siehe Challenge dauert ungewöhnlich lange.

Hinweis

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.