Spam vs. CAPTCHA

Am gestrigen Montag erreichte mich ein Hilfeschrei eines genervten Website-Besitzers: Über Nacht kamen über das ungeschützte Kontaktformular seiner brandneuen Website haufenweise Spam-Emails in sein Postfach geschwemmt. Der normale Reflex eines Webprogrammierers ist nun, einfach ein CAPTCHA einzubauen. Spammer scheuen den erhöhten Aufwand, dieses CAPTCHA lösen zu müssen und lassen den Besitzer in Frieden arbeiten.

Dennoch ist solch ein CAPTCHA eine Hürde für legitime Websitebesucher, die mit dem Anbieter in Kontakt treten wollen. Denn das CAPTCHA muss so schwer zu lösen sein, dass es nicht durch automatisierte Methoden gelöst werden kann. Selbst ich (insbesondere ich!) bin genervt von der Vielfalt der CAPTCHAs, insbesondere den Puzzle-CAPTCHA. Dass es auch ohne Benutzerinteraktion geht, beweist eine kleine Handvoll an kostenpflichtigen CAPTCHA-Anbietern wie z.B. FriendlyCaptcha.

Neben der unglaublichen Vielfalt an CAPTCHA die eine Benutzerinteraktion benötigen, gibt es also auch Lösungsmöglichkeiten, die ohne diese auskommen.

Schauen wir einmal etwas genauer hin.

Challenge-Response

CATPCHA arbeiten nach dem Challenge-Response Verfahren. Dem Besucher der Website wird ein Puzzle aufgetischt, welches er zu lösen hat. Die Lösung hat er mit den Daten des Formulars als “payload” mitzusenden. Der Anbieter prüft die Lösung vor Verarbeitung der gesendeten Formulardaten und verweigert die weitere Bearbeitung, wenn das Ergebnis des Besuchers nicht mit dem erwarteten Ergebnis übereinstimmt. Damit haben wir die ersten beiden Eigenschaften eines CAPTCHA festgelegt:

• Ein CAPTCHA muss so schwer zu lösen sein, dass der Aufwand dem Spammer zu hoch erscheint.
• Die Lösung muss mit möglichst niedrigem Aufwand überprüfbar sein.

Es gibt eine Gruppe mathematisch-kryptographischer Funtkionen, die genau diese Anforderungen erfüllt: Die Hashfunktionen. Es gibt keine Regel, dass ein CAPTCHA mit Benutzerinteraktion gelöst werden muss. Die eigentliche Regel ist: der Aufwand für die Lösung muss dem Spammer zu hoch erscheinen.

Hash-Funktionen

Ich halte mich kurz (ausnahmsweise): Wenn Sie sich für Hash- oder Streuwertfunktionen interessieren, empfehle ich Ihnen den Aktikel auf Wikipedia.

HashCash

Hashcash ist ein in den 1990er Jahren von Adam Back konzipiertes Proof-of-Work-System zur Verhinderung von Denial-of-Service-Attacken. Dies geschieht mittels einer Rechenaufgabe, die moderat schwierig aufzustellen und durchzurechnen ist, deren Lösung aber leicht zu überprüfen ist. (Quelle: Wikipedia)

Nachdem Sie nun alles über Streuwertfunktionen wissen, können wir das HashCash Verfahren auch auf Kontaktformulare anwenden.

Wir generieren ein Puzzle in Form einer Zeichenkette: 1:20:20241126:identifikator:zufallswert: und senden dieses in einem versteckten Formularfeld. Das Puzzle: Der Anwender soll solange Zahlenwerte an dieses Puzzle anhängen, bis die Steuwertfunktion eine sogenannte Teilkollision ermittelt hat, in der die 20 höchstwertigen Bits “0” enthalten. Dies ist sehr einfach zu überprüfen. Der Webbrowser sendet die Lösung dieses mathematischen Puzzle beim Absenden des Formulars mit.

 

function calcHashCash(challenge) {
    var iter = 1;
    while(response ist kein Kollisionswert) {
        c = challenge + iter
        response = streuwertfunktion(c)
        iter = iter + 1;
}

 

Da Steuwertfunktionen absolut unberechenbar sind, kann diese Aktion eine undefinierbare Zeit in Anspruch nehmen, wird aber auf jeden Fall in relativ kurzer Zeit zum Erfolg führen.

Der Server kann mit einfachsten Mitteln prüfen, ob dieser Wert tatsächlich gültig ist: Die ersten 5 Stellen von streuwertfunktion(response) muss “0” enthalten. Wenn dann noch das Datum und der Identifikator übereinstimmt, gilt das Puzzle als gelöst. Um eine Wiederverwendung von Puzzles zu verhindern, müssen gelöste Puzzles für den Rest des Tages noch in einer Datenbank gespeichert werden.