Proof of Work statt Bilderrätsel: Wie moderne CAPTCHAs Bots erkennen

Warum klassische Bilder-CAPTCHAs problematisch sind

Ein CAPTCHA – ursprünglich eine Abkürzung für „Completely Automated Public Turing test to tell Computers and Humans Apart“ – soll automatisierte Zugriffe erkennen. Typische Einsatzgebiete sind Kontaktformulare, Registrierungen, Login-Bereiche, Kommentarbereiche oder Passwort-Reset-Funktionen.

Das Grundprinzip klassischer CAPTCHAs besteht darin, eine Aufgabe zu stellen, die für Menschen einfach, für Software dagegen schwierig sein soll.

Genau diese Annahme wird zunehmend problematisch.

Bilderkennung und andere KI-Verfahren haben sich stark weiterentwickelt. Gleichzeitig können Angreifer CAPTCHA-Lösungsdienste einsetzen oder Browser automatisieren, die sich ähnlich wie reguläre Nutzer verhalten. Auf der anderen Seite müssen echte Besucher zusätzliche Aufgaben lösen. Das kostet Zeit und kann insbesondere auf Mobilgeräten störend sein.

Moderne CAPTCHA-Systeme verfolgen deshalb zunehmend einen anderen Ansatz: Nicht der Nutzer soll beweisen, dass er ein Mensch ist. Stattdessen sammelt das System technische Hinweise darauf, ob eine Anfrage wahrscheinlich von einem normalen Browser oder einer automatisierten Infrastruktur stammt.

Was bedeutet Proof of Work?

Proof of Work bedeutet zunächst lediglich, dass ein Client nachweisen muss, eine bestimmte Menge an Rechenarbeit durchgeführt zu haben.

Ein Server könnte einem Browser beispielsweise eine zufällige Zeichenfolge – eine sogenannte Nonce oder Challenge – zur Verfügung stellen. Der Browser muss anschließend einen weiteren Wert finden, bei dem das Ergebnis einer kryptografischen Hashfunktion bestimmte Bedingungen erfüllt.

Vereinfacht könnte die Aufgabe lauten:

SHA-256(Challenge + Lösung) = Hash mit vier führenden Nullen

Eine mögliche Berechnung sieht konzeptionell so aus:

Challenge + 1 → falscher Hash

Challenge + 2 → falscher Hash

Challenge + 3 → falscher Hash

...

Challenge + 18342 → 0000a74f... → gültig

Der Browser muss verschiedene Werte ausprobieren, bis eine passende Lösung gefunden wurde.

Das Interessante daran ist die Asymmetrie.

Die Lösung zu finden benötigt Rechenleistung. Die anschließend vom Server durchgeführte Überprüfung des Ergebnisses ist dagegen sehr günstig: Der Server muss lediglich einen einzelnen Hash berechnen und kontrollieren, ob dieser die vorgegebene Bedingung erfüllt.

Warum hilft Proof of Work gegen Bots?

Für einen einzelnen Nutzer ist eine kleine Rechenaufgabe kaum relevant. Benötigt der Browser beispielsweise 100 oder 200 Millisekunden für die Berechnung, wird dies in vielen Fällen nicht wahrgenommen.

Für einen Bot verändert sich die Rechnung jedoch.

Ein Spam-Bot könnte normalerweise versuchen, innerhalb kurzer Zeit Tausende Formulare abzusenden. Muss für jede Anfrage zunächst eine kryptografische Aufgabe gelöst werden, steigen die benötigte CPU-Zeit, der Energieverbrauch und letztlich die Kosten des Angriffs.

Das Ziel von Proof of Work ist deshalb nicht, eine Aufgabe zu schaffen, die ein Bot prinzipiell nicht lösen kann.

Proof of Work soll automatisierte Zugriffe teuer machen.

Das unterscheidet das Verfahren grundlegend vom klassischen Bilderrätsel. Dort soll ein Bot an einer Aufgabe scheitern, während ein Mensch sie lösen kann. Bei Proof of Work können grundsätzlich beide Seiten die Aufgabe lösen – der Unterschied liegt in den Kosten bei einer großen Zahl von Anfragen.

Gerade Spam, Credential Stuffing, Fake-Registrierungen oder automatisiertes Scraping können dadurch unattraktiver werden.

Schwierigkeit lässt sich dynamisch anpassen

Eine weitere Stärke des Verfahrens besteht darin, dass sich der benötigte Rechenaufwand verändern lässt.

Im normalen Betrieb kann eine Website eine sehr geringe Schwierigkeit verwenden. Kommt es dagegen zu einer Angriffswelle, kann das System schwierigere Aufgaben ausgeben.

Bei einem Hash-basierten Verfahren lässt sich beispielsweise festlegen, wie selten ein gültiges Ergebnis sein soll. Je höher die Schwierigkeit, desto mehr Versuche muss ein Client durchschnittlich durchführen.

Damit entsteht ein adaptives System:

Normaler Traffic → geringe Rechenarbeit

Verdächtiger Traffic → höhere Rechenarbeit

Angriffswelle → deutlich höhere Anforderungen

Ein legitimer Besucher muss dadurch nicht dauerhaft mit maximalen Sicherheitsmaßnahmen belastet werden.

SHA-256 oder Memory-Hard Proof of Work

Allerdings ist nicht jede Rechenaufgabe für jeden Angriffsfall gleich geeignet.

SHA-256 ist eine sehr verbreitete kryptografische Hashfunktion und lässt sich schnell berechnen. Gerade spezialisierte Hardware und GPUs können jedoch enorme Mengen solcher Berechnungen parallel durchführen.

Deshalb können zusätzlich sogenannte Memory-Hard-Verfahren eingesetzt werden. Diese benötigen neben Rechenleistung auch eine bestimmte Menge Arbeitsspeicher und Speicherbandbreite.

Ein Beispiel dafür ist Argon2, das ursprünglich für sicheres Passwort-Hashing entwickelt wurde. Ein Memory-Hard Proof of Work kann die massive Parallelisierung einer Aufgabe auf spezialisierter Hardware erschweren.

Auch CaptchaCore kombiniert nach Angaben des Anbieters beide Ansätze. Im normalen Betrieb kann SHA-256 zum Einsatz kommen, während bei einem erhöhten Risikoniveau auch ein Memory-Hard Proof of Work auf Basis von Argon2id verwendet werden kann. Die Berechnung erfolgt in einem WebWorker, sodass der JavaScript-Hauptthread der Website dabei nicht blockiert werden soll.

Warum Proof of Work allein nicht ausreicht

Ein wichtiger Punkt wird bei der Diskussion über Proof-of-Work-CAPTCHAs häufig übersehen:

Auch ein Bot kann die Rechenaufgabe lösen.

Ein Angreifer mit ausreichend Ressourcen könnte einfach mehr Server bereitstellen. Deshalb ist Proof of Work vor allem eine zusätzliche wirtschaftliche und technische Hürde – aber kein zuverlässiger Beweis dafür, dass hinter einer Anfrage ein Mensch sitzt.

Moderne Bot-Defense-Systeme kombinieren das Verfahren deshalb mit weiteren Schutzmechanismen.

Dazu können beispielsweise gehören:

• Verhaltensanalyse

• Browser- und Umgebungsmerkmale

• IP-Reputation

• User-Agent-Analyse

• Rate Limiting

• Erkennung ungewöhnlicher Anfragefrequenzen

• Erkennung automatisierter Browser

• Threat Intelligence

• kontextabhängiges Risk Scoring

Erst die Kombination verschiedener Signale ermöglicht eine deutlich differenziertere Entscheidung.

Beispiel CaptchaCore: Proof of Work plus Verhaltensanalyse

Wie ein solcher mehrstufiger Ansatz aussehen kann, zeigt CaptchaCore.

Das System setzt Proof of Work als erste Schutzschicht ein. Parallel analysiert das Widget verschiedene Eigenschaften der Browserinteraktion. Dazu gehören nach Angaben des Anbieters beispielsweise Mausbewegungsmuster, Tipp-Rhythmus, Scroll- und Touch-Ereignisse, Fokuswechsel sowie die Zeit zwischen Seitenaufruf und Absenden eines Formulars. Auch technische Umgebungsmerkmale wie Canvas-Timing, WebGL-Informationen oder die Ausführung von requestAnimationFrame können in die Bewertung einfließen.

Entscheidend ist dabei die Art der Verarbeitung. CaptchaCore gibt an, dass die Rohdaten von Mausbewegungen oder Tastatureingaben nicht an den Server übertragen werden. Die Daten sollen bereits im Browser zu Kennzahlen beziehungsweise Scores verdichtet werden.

Das ermöglicht beispielsweise folgende Unterscheidung:

Ein realer Besucher öffnet ein Kontaktformular, bewegt die Maus, scrollt möglicherweise etwas, wechselt zwischen Eingabefeldern und tippt seine Nachricht über mehrere Sekunden ein.

Ein automatisierter Headless-Browser kann dasselbe Formular dagegen innerhalb weniger Millisekunden aufrufen, alle Felder unmittelbar füllen und sofort absenden.

Keines dieser Merkmale allein beweist, dass es sich um einen Bot handelt. Zusammen können die Signale jedoch ein auffälliges Muster ergeben.

Aus vielen Signalen wird ein Risk Score

Die eigentliche Entscheidung findet bei modernen Systemen deshalb häufig nicht im Browser, sondern serverseitig statt.

CaptchaCore verwendet dafür eine sogenannte Adaptive Risk Engine. Sie bewertet unter anderem die Proof-of-Work-Lösung, Verhaltenssignale, Browserumgebung sowie weitere Kontextinformationen. Das System erzeugt daraus einen Risk Score und kann eine Anfrage beispielsweise zulassen, blockieren oder eine zusätzliche Prüfung verlangen.

Interessant ist dabei auch der Kontext des Formulars.

Eine Kontaktanfrage besitzt ein anderes Risikoprofil als ein Login-Versuch. Bei einem Login können automatisierte Angriffe beispielsweise dazu dienen, gestohlene Benutzername-Passwort-Kombinationen massenhaft auszuprobieren.

CaptchaCore kann deshalb unterschiedliche Form-Policies verwenden. Laut Dokumentation lassen sich unter anderem Login, Registrierung, Checkout und Kontaktformular unterschiedlich bewerten.

Damit wird aus einem einfachen CAPTCHA zunehmend ein kleines Bot-Defense-System.

Schutz vor dem Wiederverwenden einer gültigen Lösung

Auch der Proof of Work selbst benötigt zusätzliche Schutzmechanismen.

Könnte ein Bot eine einmal berechnete Lösung beliebig oft wiederverwenden, wäre der Aufwand schnell wieder minimal.

Daher kommen üblicherweise einmalige Challenges beziehungsweise Nonces zum Einsatz.

Bei CaptchaCore sind Nonces laut technischer Dokumentation nur einmal verwendbar und besitzen eine begrenzte Gültigkeitsdauer. Außerdem werden Challenge-Bindings mit Ed25519 signiert und unter anderem an Site, Origin und Formulartyp gebunden. Damit soll verhindert werden, dass eine gültige Lösung einfach auf einer anderen Website oder für andere Anfragen wiederverwendet wird.

Der Ablauf lässt sich damit vereinfacht folgendermaßen darstellen:

1. Website wird geladen

Das CAPTCHA-Widget wird im Browser gestartet.

2. Server liefert eine Challenge

Der Client erhält eine einmalige kryptografische Aufgabe und die dazugehörigen Parameter.

3. Browser berechnet den Proof of Work

Die Berechnung findet lokal statt.

4. Gleichzeitig werden Risikosignale ermittelt

Verhaltens- und Browsermerkmale werden analysiert.

5. Es entsteht ein Verifikationstoken

Proof-of-Work-Ergebnis und weitere Informationen werden zusammengeführt.

6. Der Webserver überprüft das Token

Die Website übermittelt das Token serverseitig an die CAPTCHA-API.

7. Die Risk Engine entscheidet

Die Anfrage wird zugelassen, zusätzlich geprüft oder blockiert.

CaptchaCore dokumentiert für seine API entsprechend die möglichen Entscheidungen allow, challenge, step_up und block. Zusätzlich können Risk Score, Confidence-Wert und Reason Codes zurückgegeben werden.

Was passiert bei einem größeren Bot-Angriff?

Besonders interessant wird ein adaptives CAPTCHA, wenn sich die Bedrohungslage verändert.

Bei CaptchaCore existiert hierfür beispielsweise ein mehrstufiger „Under-Attack-Mode“. Steigt der Anteil blockierter Anfragen, kann das System die Anforderungen verschärfen. Dabei können unter anderem die Proof-of-Work-Schwierigkeit erhöht, strengere Heuristiken verwendet oder zusätzliche Interaktionsprüfungen aktiviert werden. Auf der höchsten dokumentierten Stufe wird Memory-Hard Proof of Work zusammen mit einer zusätzlichen Interaktionsprüfung eingesetzt.

Damit ähnelt das Prinzip einer adaptiven Firewall:

Solange der Traffic normal aussieht, bleiben die Sicherheitsmaßnahmen möglichst unauffällig. Erst wenn ungewöhnliche Muster auftreten, steigt die Hürde.

Proof of Work verbessert auch die Nutzererfahrung

Der technische Ansatz hat noch einen weiteren Vorteil: Besucher müssen nicht zwangsläufig aktiv mit dem CAPTCHA interagieren.

Die Rechenaufgabe kann im Hintergrund ausgeführt werden, während der Nutzer ohnehin das Formular ausfüllt. Bei einem niedrigen Risikoscore kann das System die Anfrage anschließend ohne Bilderrätsel oder zusätzliche Aufgabe freigeben.

CaptchaCore stellt beispielsweise einen „Invisible“- sowie einen „Interactive“-Modus bereit. Im Interactive-Modus kann die Prüfung automatisch abgeschlossen werden, wenn genügend passende Interaktionssignale vorhanden sind. Im Invisible-Modus läuft die Prüfung komplett im Hintergrund. Daneben steht weiterhin eine sichtbare Variante mit manueller Interaktion zur Verfügung.

Gerade für Kontaktformulare, Registrierungen und Login-Bereiche kann dies die Hürde für reale Nutzer reduzieren.

Datenschutz als weiterer Faktor

Behavioral Analysis und Browser-Fingerprinting werfen zwangsläufig Datenschutzfragen auf. Entscheidend ist deshalb nicht nur, welche Signale ein System verwendet, sondern auch, wie diese verarbeitet und gespeichert werden.

CaptchaCore verfolgt hier laut Anbieter einen Privacy-by-Design-Ansatz. Verhaltensdaten sollen bereits im Browser aggregiert werden, während keine Rohdaten von Tastatureingaben oder Mausbewegungen übertragen werden. Die eigentliche Verifikation und Risk Engine laufen nach Herstellerangaben auf Servern in Deutschland. Im normalen Betrieb sollen außerdem keine persistenten Cookies erforderlich sein.

Ob und welche datenschutzrechtlichen Informationspflichten beim Einsatz eines externen CAPTCHA-Dienstes bestehen, sollte dennoch für das jeweilige Projekt individuell geprüft werden.

Fazit: Moderne CAPTCHAs versuchen Bots zu bewerten statt Menschen zu testen

Das klassische CAPTCHA basiert auf einer einfachen Idee: Der Besucher erhält eine Aufgabe, die Menschen lösen können und Computer nicht.

Durch moderne Bilderkennung, automatisierte Browser und KI wird diese Grenze jedoch zunehmend unscharf.

Proof of Work kehrt das Prinzip teilweise um. Der Client muss keine menschliche Fähigkeit demonstrieren, sondern eine kleine Menge Rechenarbeit erbringen. Für einen einzelnen Besucher ist diese Arbeit kaum relevant, bei Millionen automatisierter Anfragen können die Kosten dagegen erheblich steigen.

Allein reicht Proof of Work allerdings nicht aus. Bots können ebenfalls rechnen. Seine Stärke entfaltet das Verfahren deshalb vor allem als Teil eines mehrschichtigen Schutzsystems.

Lösungen wie CaptchaCore kombinieren den kryptografischen Arbeitsnachweis deshalb mit Verhaltensanalyse, Browser- und Umgebungssignalen, IP-Reputation, Threat Intelligence und einer adaptiven Risk Engine. Statt jeden Besucher mit demselben Bilderrätsel zu konfrontieren, wird für jede Anfrage bewertet, wie wahrscheinlich ein automatisierter Zugriff ist.

Damit entwickelt sich das klassische CAPTCHA zunehmend von einer sichtbaren Aufgabe für den Menschen zu einem weitgehend unsichtbaren Sicherheitssystem im Hintergrund.