Proof-of-Work-Captcha: So arbeiten Captchas ohne Bilderrätsel
Ihr Server nimmt ein Formular erst an, wenn der Browser vorher eine kleine Rechenaufgabe erledigt hat. Das ist das ganze Prinzip eines Proof-of-Work-Captchas. Lösen lässt sich die Aufgabe nur durch Ausprobieren, prüfen kostet den Server eine einzige Berechnung. Wer ein Formular abschickt, bemerkt davon kaum etwas; ein Bot, der tausend Formulare abschicken will, zahlt tausendmal. Dass ein Mensch vor dem Bildschirm sitzt, beweist das allerdings nicht, weshalb die meisten kommerziellen Anbieter die Rechnung mit weiteren Signalen kombinieren.
Woher die Idee stammt
Die Idee ist älter als das Web-Formular. 1992 schlugen Cynthia Dwork und Moni Naor auf der Konferenz CRYPTO eine Bremse für Junk-Mail vor: Wer eine Ressource wie ein E-Mail-Postfach nutzen will, soll vorher eine „moderately hard, but not intractable“ Funktion berechnen. Ihr Wort dafür war „pricing function“, bezahlt wird mit Rechenzeit. Adam Back kam 1997 unabhängig davon auf Hashcash, das partielle Hash-Kollisionen sucht. Erst in seinem Paper von 2002 heißt das Ergebnis ausdrücklich „proof-of-work“, und die Anforderung an so eine Kostenfunktion passt bei ihm in einen Halbsatz: „efficiently verifiable, but parameterisably expensive to compute“.
Gedacht war das alles gegen Spam-Mails. Ins Web kam die Idee zurück, als Bilderrätsel immer weniger halfen. Sichtbare Captchas, schreibt OWASP heute, seien von Maschinen lösbar und würden an Klickfarmen ausgelagert.
Der Ablauf in vier Schritten
| Schritt | Wer | Was passiert |
|---|---|---|
| 1 | Server | schickt eine Aufgabe: einen zufälligen Wert (Salt) und eine Schwierigkeit, meist signiert, damit niemand sie fälschen kann |
| 2 | Browser | probiert Zahlen durch, bis das Ergebnis einer Hash-Funktion die Vorgabe erfüllt; je nach Anbieter mit SHA-256 oder speicherintensiven Verfahren wie Scrypt oder Argon2id |
| 3 | Ihr Server | bekommt die Lösung mit dem Formular und prüft sie beim Anbieter oder selbst mit einer einzigen Berechnung |
| 4 | beide | jede Lösung gilt nur einmal und nur für kurze Zeit; ALTCHA empfiehlt Ablaufzeiten zwischen 20 Minuten und einer Stunde, Cloudflare Turnstile lässt Tokens nach fünf Minuten verfallen |
Wie schwer die Aufgabe ausfällt, entscheidet der Server, und zwar nicht unbedingt bei jedem Besuch gleich. Bei mCaptcha steigt die Schwierigkeit, wenn viele Anfragen auf einmal kommen; die Dokumentation nennt dafür Schwellenwerte für die Zahl der Besucher. Andere Anbieter bewerten jeden Besuch einzeln und geben verdächtigen Browsern die größere Aufgabe. Und die Hardware? Eine Grafikkarte rechnet einfache Hash-Funktionen deutlich schneller als ein Smartphone. Laut ALTCHA schrumpft dieser Vorsprung bei speicherintensiven Verfahren wie Argon2id.
Wo die Grenzen liegen
Ben Laurie und Richard Clayton haben 2004 nachgerechnet, ob Proof of Work gegen E-Mail-Spam taugt. Ihr Paper heißt „Proof-of-Work Proves Not to Work“. Eine Schwierigkeit, die Spammer wirklich bremst, hätte nach ihrer Rechnung auch normale Nutzer spürbar belastet, und wer viele gekaperte Rechner hat, zahlt den Preis ohnehin leichter als ein einzelner Besucher mit altem Laptop. Wie weit Geräte damals auseinanderlagen, steht in einem Satz des Papers: „Work that might take 10 seconds on a 3GHz Pentium could take an hour or more on a Palm Pilot.“
Im OWASP Bot Management Cheat Sheet ist der Einwand auf einen Halbsatz geschrumpft. Proof of Work „can increase automation cost but does not establish that the client is human“. Zu schwere Aufgaben, heißt es dort weiter, können legitime Nutzer aussperren.
Wer reines Proof of Work sucht, landet deshalb vor allem bei Open-Source-Projekten wie ALTCHA (Grundversion) oder mCaptcha. Kommerzielle Dienste koppeln die Rechnung an Risikosignale aus dem Browser, und von denen hängt ab, wie schwer die Aufgabe wird.
Unsichtbare Verfahren im Vergleich
| Verfahren | Beispiele | Was geprüft wird | Was der Besucher merkt |
|---|---|---|---|
| reines Proof of Work | ALTCHA (Open Source), mCaptcha | Rechenaufgabe mit fester oder lastabhängiger Schwierigkeit | kurze Wartezeit |
| Rechenaufgabe mit Risikosignalen | Friendly Captcha v2, ALTCHA Sentinel, Myra EU CAPTCHA | Browser- und Gerätemerkmale bestimmen die Schwierigkeit der Aufgabe | meist nichts; bei Verdacht je nach Anbieter längere Rechenzeit (Myra: bis rund 30 Minuten) oder eine zusätzliche Interaktion (Friendly Captcha im Modus „Smart“: unter Umständen ein Klick; ALTCHA Sentinel: interaktive Prüfung) |
| Signalprüfung im Browser | Cloudflare Turnstile | laut Cloudflare unter anderem Proof of Work, Proof of Space und Abfragen von Web-APIs | je nach Modus nichts oder eine Checkbox |
| reiner Risikowert | Google reCAPTCHA v3 | Verhalten auf der Seite, Ergebnis ist ein Wert zwischen 0,0 und 1,0 | nichts; die Entscheidung trifft Ihr Server |
| Bestätigung durch das Gerät | Privacy Pass (RFC 9576 bis 9578), Apple Private Access Tokens | ein Aussteller bestätigt per Token, dass der Client eine Prüfung bestanden hat, etwa einen Gerätecheck, ohne Identität preiszugeben | nichts, auf unterstützten Geräten |
Bei Login-Formularen spricht ein Punkt klar für die Rechenaufgabe. Erfolgskriterium 3.3.8 von WCAG 2.2 (Stufe AA) verlangt bei Anmeldeschritten eine Alternative zu kognitiven Tests wie Abtippen, Rechnen oder Rätseln. Den Browser im Hintergrund rechnen zu lassen, verlangt vom Menschen nichts davon. Unzulässig sind Bilderrätsel deshalb nicht automatisch: Das Erkennen von Objekten auf Bildern nimmt WCAG 2.2 auf Stufe AA ausdrücklich aus.
So macht es Myra EU CAPTCHA
In der Tabelle steht Myra EU CAPTCHA in der zweiten Zeile. Beim Laden der Seite erhebt das Widget laut Dokumentation Browser- und Gerätemerkmale aus sieben Gruppen, darunter Hardware und Netzwerk (auch Adressen aus WebRTC), außerdem Verhalten wie Mausbewegungen und Scrollen sowie Hinweise auf Automatisierung. Der Dienst berechnet daraus einen Risikowert. Je höher er liegt, desto aufwendiger wird der anschließende Proof of Work mit Argon2id. Wie lange das dauert, hängt also vom einzelnen Besuch ab: im Regelfall rund 600 Millisekunden, bei sehr hohem Risiko bis zu rund 30 Minuten. Jedes Token nimmt der Server genau einmal an. Und weil die Frage nach § 25 TDDDG regelmäßig kommt: Cookies setzt das Widget nicht. Browser-Merkmale und Verhaltenssignale wertet es aber aus. Und eine lange Rechenzeit nach einer Fehleinstufung kann ihrerseits Menschen ausschließen. Was daraus folgt, steht im Beitrag Captcha und Einwilligung.
Weitere Wege, ein Formular zusätzlich abzusichern, vom Honeypot bis zur Zeitprüfung, sammelt der Beitrag Spam im Kontaktformular verhindern.
Häufige Fragen
Beweist ein Proof-of-Work-Captcha, dass ein Mensch vor dem Bildschirm sitzt?
Nein, und das sagt auch OWASP. Im Bot Management Cheat Sheet steht, Proof of Work könne die Kosten der Automatisierung erhöhen, belege aber nicht, dass der Client ein Mensch ist. Die meisten Anbieter verbinden die Rechenaufgabe deshalb mit weiteren Signalen.
Merkt man als Besucher etwas von der Rechenaufgabe?
Meistens nicht. Myra EU CAPTCHA zum Beispiel bemisst die Aufgabe für einen gewöhnlichen Besuch auf rund 600 Millisekunden und lässt sie nur wachsen, wenn der Besuch verdächtig wirkt. Wo die Grenze liegt, beschäftigt die Fachwelt seit Langem: OWASP warnt, zu schwere Rätsel könnten legitime Nutzer aussperren, und Laurie und Clayton rechneten schon 2004 vor, wie weit ältere Geräte hinter schnellen Rechnern zurückbleiben.
Ist ein Proof-of-Work-Captcha dasselbe wie Krypto-Mining?
Verwandt ja, gleich nein. Laut hashcash.org steckt Hashcash, 1997 vorgeschlagen, heute vor allem im Bitcoin-Mining. Ein Captcha schürft trotzdem nichts: Der Browser rechnet eine einzige kurze Aufgabe, und deren Ergebnis gilt nur für diese eine Formularanfrage.
Braucht ein Proof-of-Work-Captcha Cookies?
Nach Angaben von ALTCHA und Myra EU CAPTCHA kommen beide ohne Cookies aus. Technisch nötig sind sie dafür nicht, denn die Aufgabe liefert der Server, und das Ergebnis reist als Token mit dem Formular zurück. Ob ein Captcha trotzdem unter § 25 TDDDG fällt, weil es Browser-Merkmale ausliest, ist eine eigene Frage.
Quellen
- Dwork, Naor: Pricing via Processing or Combatting Junk Mail, CRYPTO ’92 (DOI), abgerufen am 11.10.2026
- Dwork, Naor: Pricing via Processing, Volltext (Weizmann Institute), abgerufen am 11.10.2026
- Back: Hashcash – A Denial of Service Counter-Measure (2002), abgerufen am 11.10.2026
- Laurie, Clayton: „Proof-of-Work“ Proves Not to Work (WEIS 2004), abgerufen am 11.10.2026
- OWASP Bot Management and Anti-Automation Cheat Sheet, abgerufen am 11.10.2026
- ALTCHA, How it works, abgerufen am 11.10.2026
- ALTCHA, Proof-of-Work Captcha, abgerufen am 11.10.2026
- mCaptcha, Configuring difficulty factor, abgerufen am 11.10.2026
- Friendly Captcha, Developer Docs v2, abgerufen am 11.10.2026
- Google, reCAPTCHA v3, abgerufen am 11.10.2026
- Cloudflare, Turnstile, abgerufen am 11.10.2026
- IETF, RFC 9576: The Privacy Pass Architecture, abgerufen am 11.10.2026
- Apple Developer News, Private Access Tokens (2022), abgerufen am 11.10.2026
- W3C, Understanding WCAG 2.2: Accessible Authentication (Minimum), abgerufen am 11.10.2026
- EU CAPTCHA Dokumentation, Funktionsweise, abgerufen am 11.10.2026