Proof of Work

Jede Verifizierung bittet den Browser des Besuchers, ein kleines Rechenrätsel zu lösen, bevor Caputchin ein Token ausgibt. Dieses Rätsel ist der Proof of Work.

Wie es funktioniert

Caputchin reicht dem Browser eine Challenge und bittet ihn, eine Zahl (eine Nonce) zu finden, die, zusammen mit der Challenge gehasht, einen Hash erzeugt, der mit einer geforderten Anzahl führender Nullen beginnt. Es gibt keine Abkürzung: der Browser muss Nonce um Nonce probieren, bis eine zufällig funktioniert. Eine gültige Nonce zu finden braucht viele Versuche; eine zu prüfen ist ein einzelner Hash. Die Arbeit ist also schwer zu leisten, aber billig zu verifizieren, und Caputchin bestätigt, dass die Antwort die geforderte Schwierigkeit erreicht.

Content-Security-Policy

Der Löser läuft in einem Web Worker, den das Widget aus einer blob:-URL erstellt, also muss die Content-Security-Policy der einbettenden Seite blob: für Worker erlauben (worker-src blob:, oder child-src / default-src als Fallback-Kette). Dieser Teil ist Pflicht: es gibt keinen Main-Thread-Fallback, also blockiert eine Policy, die den Worker blockiert, die Verifizierung. Separat führt der Löser für Tempo eine WebAssembly-Routine aus, und das braucht zwei Erlaubnisse statt einer: er holt das Modul per fetch von neben dem Widget-Skript, also muss dieser Origin in connect-src stehen, und er kompiliert das Modul, wofür 'wasm-unsafe-eval' in script-src nötig ist. Dieser Teil ist optional: fehlt eins von beiden, läuft derselbe Löser langsamer in reinem JavaScript im Worker. Und es passiert still, denn der Rückfall ist kein Fehler, also prüf beides, wenn sich das Lösen unter einer strikten Policy zäh anfühlt. Sieh dir Spiel-Sandboxing für die vollständige Host-Seiten-Policy an.

Warum es Missbrauch abschreckt

Der Punkt ist nicht, irgendeine einzelne Lösung unmöglich zu machen. Es ist, Missbrauch im großen Maßstab unwirtschaftlich zu machen.

Ein echter Besucher löst ein Rätsel in einem Sekundenbruchteil und merkt es nie. Ein Bot, der tausende Anfragen feuern will, zahlt diese Rechenkosten tausendfach. Wenn das Lösen der Challenge mehr kostet, als der Spam wert ist, hört der Angriff auf, finanziell Sinn zu ergeben. Proof of Work verschiebt das Ziel von "unknackbar" zu "nicht der Mühe wert".

Die Regler

Zwei Einstellungen auf der Sicherheit-Seite eines Keys justieren die Kosten:

• Schwierigkeit setzt, wie viele führende Nullen der Hash haben muss, was die Kosten jeder Lösung erhöht.
• Challenges pro Anfrage vervielfacht diese Kosten, indem mehrere Lösungen auf einmal verlangt werden.

Eine ehrliche Grenze

Keine Challenge ist unknackbar; mit genug Geld lässt sich alles lösen. Proof of Work akzeptiert das und konkurriert stattdessen über die Kosten. Es beweist auch nur, dass Aufwand aufgewendet wurde, nicht dass ein echter Browser ihn aufwendete, weshalb Caputchin es mit Instrumentierung paart, um auch die Umgebung zu prüfen.