Navigation überspringen

Usability-Verbesserungen bei meinem 8-zeiligen WordPress-Captcha

18.1.2021·Kommentare:  7Retweets:  0 2

Vor kurzem habe ich auf Twitter eine Diskussion über Spamschutz-Möglichkeiten in WordPress verfolgt. Robert (der eben auf WordPress umgestiegen ist), erwähnte dabei eine aus seiner Sicht problematische Lösung, die mir irgendwie bekannt vorkam.

Das Problem

Der Spamschutz im (dankenswerterweise nicht namentlich 😉 ) genannten Beispiel war dabei als simple Sicherheitsfrage in Form einer Rechenaufgabe mit den Worten »Zwei + Eins =« formuliert. Problematisch war dabei die gewünschte Antwort, die als Lösung nicht »Drei«, sondern die Ziffer »3« verlangte. Bekannt kam mir das Beispiel deswegen vor, weil es sich dabei um meine eigene, selbstgestrickte Lösung zum Schutz vor Spamkommentaren handelte. Ups. So betrachtet natürlich blöd und aus der Sicht eine Außenstehenden auch nachvollziehbar. Bevor wir zu meinen diesbezüglichen Verbesserungen kommen, zunächst die kurze Geschichte, wie ich überhaupt auf diese Lösung gekommen bin.

Eine simple Grundidee …

Niemand mag Captchas. Also war mein ursprünglicher Ansatz gar kein Captcha zu verwenden. Spammer hätten ohnehin keine Chance, weil ich alle Kommentare manuell freischalte. Allerdings hat es mich irgendwann genervt, mehrmals täglich über neue Kommentare informiert zu werden, die dann eben nur Spam waren. Auf Akismet wollte ich einerseits aus Datenschutzgründen verzichten, andererseits wollte ich aber auch kein komplexes anderes Tool einsetzen. Also entschied ich mich schrittweise vorzugehen und zunächst zu testen, ob nicht eine simple Sicherheitsfrage – vor allem für ein Blog mit begrenzter Reichweite (kein lohnendes Ziel für Spammer) – bereits reicht.

… mit einem Haken

Als ich meinen recht einfachen Spamschutz zum ersten Mal implementierte, lautete die Frage tatsächlich »1 + 2 =« (eventuell mit anderen Zahlen, jedenfalls aber mit Ziffern und nicht ausgeschrieben). Allerdings dauerte es nicht lange, bis wieder die ersten Spamkommentare in der Moderationsansicht auftauchten. Die Sicherheitsfrage war wohl zu simpel und einfach als Addition zu parsen und somit leicht automatisiert umgehbar.

Verschlimmbesserung oder nur ein »Kajak«-Problem?

Für den nächsten Schritt war meine Überlegung die Frage komplizierter zu machen: Die Ziffern ausgeschrieben, sowie einerseits auf Deutsch und andererseits mit unsichtbaren HTML-Entities »zerstückelt« um das Parsen zu erschweren. Die Lösung blieb aber weiterhin »3« (um die Eingabe weiterhin mit einem Tastendruck zu ermöglichen). Ich dachte mir zwar bereits damals, dass eine in Worten ausgeschriebene Rechenaufgabe den Eindruck vermitteln würde als Lösung ebenfalls die ausgeschriebene Zahl zu verlangen, stufte das Problem aber nach Steve Krug als »Kajak«-Problem ein. Aus einem meiner frühen Lieblingsbücher zum Thema Webusability, »Don’t make me think! Web Usability – Das intuitive Web«, Seite 179:

Ignorieren Sie ›Kajak‹-Probleme. In jedem Test gibt es wahrscheinlich einige Fälle, bei denen sich die Anwender für einen kurzen Moment verlaufen, aber fast sofort wieder ohne Unterstützung den richtigen Weg finden können. Es hat Ähnlichkeit mit dem Kentern im Kajak – wenn sich der Kajak nur schnell genug wieder aufrichtet, gehört das alles zum so genannten Spaß. Beim Basketball sagt man: kein Schaden, kein Foul.

Meine Annahme war also, dass User vielleicht versuchen würden, die Lösung auszuschreiben. Da die Zeichenanzahl aber auf 1 beschränkt und das Eingabefeld für genau diese Länge angepasst war, würden sie aber schnell erkennen, dass hier »3« und nicht »Drei« verlangt wird – eine Kajakrolle quasi.

Ich entschied mich dafür, weil ich mein Kommentarformular so schlicht wie möglich halten wollte. Damit in der Mobilansicht die Rechenaufaufgabe noch in eine Zeile mit dem Kommentieren-Button passt, wollte ich das Feld auch nicht länger machen. Und ich wollte auch nicht beide Lösungen ermöglichen – denn dann könnten User beim Eingabefeld noch verwirrter sein: »Es ist zwar nur so breit wie ein Zeichen, erlaubt aber auch die Eingabe mehrere Zeichen – ist hier nun »3« oder »Drei« als Lösung gefordert?«

»Don’t make me think!«

Nichtsdestotrotz: Man sieht die Rechenaufgabe, die Wörter sind ausgeschrieben und nichts deutet darauf hin, dass hier nur die Ziffer gefordert wird. Das widerspricht jedenfalls dem Grundsatz des zuvor zitierten Buches: »Don’t make me think!« Und auf derselben Seite ist einige Absätze weiter unten zu finden:

Wenn es natürlich einen einfachen und nahe liegenden Weg zur Reparatur gibt, der nicht alles andere einstürzen lässt, sollten Sie das auf alle Fälle nachbessern

Das rückt das oben etwas aus dem Zusammenhang gerissene Zitat auch wieder in den eigentlichen Kontext. Denn des Vergleichs der Kajakrolle sollte man sich nur bedienen, wenn es sich dabei um ein kleines Problem einer eigentlich guten aber großen, aufwändigen Lösung handelt – und das ist bei einer Sicherheitsfrage eigentlich nicht der Fall.

Ich war also schon drauf und dran, als Lösung auch einfach das Wort »Drei« zu erlauben. Dazu eventuell das Eingabefeld breiter zu machen, vielleicht sogar mit hilfreichem Placeholder-Text wie »Ziffer oder ausgeschrieben« (leider gibt es in HTML5 keine standardisierte Tooltip-Möglichkeit, die auch auf Touchdevices funktioniert).

Zurück zum Anfang

Dann bin ich jedoch einen Schritt zurückgegangen. Wenn durch das Ausschreiben der Ziffern und einer mit HTML-Entities versehenen Rechenaufgabe praktisch alle Spamkommentare abgefangen werden, dann reicht diese Taktik vielleicht auch für Ziffern – denn auch diese kann man als Entity-Code angeben und auch den Operator etwas »verstecken«. Und auch wenn es noch keine ideale, simple Tooltip-Möglichkeit gibt, so habe ich zumindest auch einen entsprechenden Title-Tag mit Hinweis vergeben.

Diese Lösung habe ich vor ungefähr zwei Wochen implementiert. Nach ungefähr 24 Stunden landeten zwar bereits zwei Spamkommentare in der Moderationsansicht und ich dachte schon, der Ansatz würde nicht funktionieren, seitdem ist es aber ruhig.

Ich beobachte die Situation weiter und werde gegebenfalls erneut Anpassungen vornehmen, aber bis dahin ist die Sicherheitsfrage wieder wie eine Rechenaufgabe formuliert und erwartet als Eingabe eine Ziffer.

Update: Ich habe mich spontan dazu entschieden, die Honeypot-Variante auszprobieren.

Eure Meinung?

Was meint ihr? Findet ihr die Lösung gut oder würdet ihr sie verbessern? Und wenn ja, wie? Über Feedback dazu freue ich mich wie immer in den Kommentaren!


Neueste Artikel

Schlagwörter

· ·


7 Kommentare

Hier (4) · Twitter (3) · Facebook (0)

#1 von Robert Lender am 19.1.2021, 19:35 Uhr

Danke für deine Überlegungen. Interessant zu lesen. Ich wünsche dir, dass das Spam-Aufkommen weiterhin bei fast Null bleibt.
Wie wäre es eigentlich mit einem Honeypot statt einem Captcha. Hast du dir das schon überlegt? Und wenn ja, warum war es dann nichts für dich?

Danke nochmals, dass du meine (nicht namentliche 😉 ) Erwähnung positiv aufgenommen hast.

#2 von Fritz am 19.1.2021, 20:48 Uhr

Hallo,
wenn ein Pflichtfeld nicht oder falsch ausgefüllt ist, gibt es eine passende Fehlermeldung.
Wenn ich aber die Rechenaufgabe falsch löse, dann passiert nach Klick auf »Kommentieren« einfach gar nichts?
Absicht?

#3 von Benedikt am 20.1.2021, 11:03 Uhr

Robert, vielen Dank und selbstverständlich nehme ich das gerne positiv auf! 😉

Mit der Honeypot-Idee hatte ich auch gespielt, war mir aber bezüglich Accessibility nicht sicher. Das Feld müsste meiner Meinung nach so benannt sein, dass das Leerlassen auf jeden Fall ersichtlich ist – und dann könnten das auch Spambots »verstehen«. Zumindest sollte das Feld dann nicht offensichtlich »E-Mail« oder »Anrede« heißen. Ich könnte aber einmal testen, wie gut ein Feld mit »Zum Spamschutz leerlassen« funktioniert. Das wäre dann halbwegs accessibilityfreundlich. Eventuell muss ich mich hier auch erst einmal auf den neuesten Stand bringen, ob hier nicht ein simples »display:none;« via CSS auch reicht.

#4 von Benedikt am 20.1.2021, 11:04 Uhr

Hi Fritz, vielen Dank für dein Feedback! Ja, das ist Absicht und quasi ein halber Honeypot. 😉 Ich kann testhalber eine korrekte Fehlermeldung ausgeben und testen, ob es Bots gibt, die die Rückmeldung verstehen und umgehen können. Die Fehlerbehandlung wird zudem in erster Linie mit required- und type-Attributen via HTML5 abgehandelt und da gibt es leider noch keine Möglichkeit, auf einen konkreten Wert einzuschränken (mit PHP, JS etc. natürlich schon, wollte aber schauen, mit wie wenig ich durchkomme 😉 ). Weil die Lösung zudem (auch accesilbilitytechnisch) offensichtlich ist, dachte ich, ich könnte ohne eine Fehlermeldung auskommen (siehe auch »Kajak«-Problem oben) – aber ja, strenggenommen ist es ein UI-Fehler.

Kommentieren

Am liebsten hier, gerne aber auch auf Twitter und Facebook.
Ich freue mich über jeden Kommentar und antworte gern innerhalb von 24 Stunden.