Idee für barrierearme Anti-Bot Formulare

[phpBuddy]

Hallo,

das Problem mit Spambots in GBs, Newskommentaren, usw. kennt jeder von uns. Anti-Bot Maßnahmen gibt es auch die verschiedensten, aber selbst CAPTCHAS halten mittlerweile nur noch mittelmäßige bis schlechte Bots ab. Die Methode die ich bisher einsetze und die eine Hundert prozentige Quote hat, was das abhalten von Bots in sichtbaren Bereichen einer Seite angeht, ist das nachträgliche aktivieren eines Eintrags per Email. Diese Methode hat allerdings auch Haken, wenn z.B. ein User trotz Hinweis eine Fake Email angibt. Andere User hält es ganz ab, weil es denen zu aufwändig ist.

Jetzt frage ich mich gerade, wie die Aussichten auf ein spamfreies GB o.ä. wären, wenn man ganz auf CAPTCHA und Email-Aktivierungen verzichtet und sich einen Eintrag vom User auf der Danke-Seite aktivieren läßt?!

Die Idee:
Ein User kommt auf die Seite, wo eine Session gestartet und ein Hash in der Session abgelegt wird. Das passiert beim Erstbesuch auf jeder Seite, außer der Seite die ein Formular beinhaltet. So verhindert man, dass "Leute" die eine Seite mit einem Formular direkt aufrufen (was Bots idR machen) ebenfalls so einen Hash bekommen. Jetzt macht der User einen Eintrag und wird bei einem korrekt ausgefüllten Formular auf eine Danke-Seite weitergeleitet. Dort steht aber eben nicht nur ein "Danke", sondern auch ein Aktivierungslink des eben getätigten Eintrags, bei dem per GET-Parameter der Hash aus der Session übergeben wird. Jetzt werden beide Werte miteinander verglichen und stimmen diese überein, wird der Eintrag freigeschaltet. Stimmen die Werte nicht überein, bzw es gibt gar keine Werte, weil die Session nicht gesetzt wurde, bleibt der Eintrag zur endgültigen Prüfung deaktiviert in der DB stehen.

Das Prinzip ist ähnlich der Email-Aktivierung, nur das man komplett auf das abfragen der Email verzichten kann und der User erst Emails prüfen muß. Es gibt auch keine Dinge im Formular wie versteckte Felder, CAPTCHA o.ä., die sich auf die Nutzbarkeit auswirken könnten. Es müsste lediglich ein zusätzlicher Link geklickt werden, was ein Bot ja nicht macht.

Bisher ist mir so ein System noch nicht begegnet. Kennt das schon jemand von einer anderen Seite? Oder hat das sogar schon im Einsatz? Oder erkennt Schwachstellen (abgesehen von der erzwungenen Session) in dieser Idee, die mir entgangen sind?

Was haltet Ihr von dieser Idee? Würde mich über Meinungen freuen.

[Boris]

Irgendwie bin ich kein persönlicher Fan davon, bei einem Besuch eines Users gleich Sessions zu starten.

Bis jetzt habe ich einen ultrasimplen Captcha genutzt, der bis heute ungebrochen ist - indem ich Frage "was ist der erste Buchstabe des Wortes Hallo"?

Keine schwere Frage ... inwieweit das barrierefrei ist, kann ich natürlich nicht beantworten.

[chorn]

Hi,

hat schonmal jemand erfahren, wie Bots auf Checkboxen reagieren? Ob der Status geändert wir, ob grundsätzlich alle aktiviert werden, ob sie einfach so gelassen werden wie sie sind...

MfG, Christian.


---------------------------------------------------------------


Achja,

ansonsten finde ich eure Ideen sehr ansprechend!

MfG, Christian.

[Peter]

Hallo,

die Idee von Rizzo ist sicher gut. Das Ganze wird aber auch nur so lange funktionieren solange es unentdeckt und unbekannt bleibt genauso wie Boris Buchstaben-Captcha.
Zweiter Nachteil: ist eben nur auf "Extra"-Formularseiten anwendbar. Bei Blogs, Foren, Artikel wo Content und Formular auf einer Seite sind funktionierts ja wie du geschrieben hast nicht.

[steffenk]

@Boris: Usersessions sind kein Nachteil. bei vielen Seiten braucht man sie eh um bereits getätigte Schritte zu speichern um sie jederzeit fortführen zu können, also in jedem Fall ein Nutzen von Userseite.

@Andreas - die Idee ist nicht schlecht und ich würde es einfach mal probieren. Oft zeigen sich Mängel erst in der Praxis. Am besten wäe natürlich die Umgestaltung eines Formulars, das schon Spamangriffen ausgesetzt ist.

Ich glaube aber nicht das Bots nur direkte POST-requests nutzen, die haben auch gelernt und sind schlauer geworden. Ein Bot kann genauso gut eine Seite besuchen und somit eine Usersession bekommen, ebenso können Sessions gehijackt werden.

Ich fahre bis jetzt immer noch am besten mit einer ganz simplen JS-Lösung, wo beim submit im onclick erst der target gesetzt wird, also ein echtes Userklicken benötigt - seit 1 Jahr 100% spamfrei.

[Bruecksen]

Die Idee finde ich gut. Kenne das von folgendem Gästebuch Skript http://obsession-design.de/scripte/odgb/. Ich weiß nicht wie das ganze dort umgesetzt ist, es ist vom Ablauf aber wie du es beschrieben hast. Der Nutzer, kann den Beitrag den er geschrieben hat nach dem klick auf senden, "bearbeiten" und oder "freischalten". Captcha und eMail Aktivierung gibt es allerdings auch als zusätzliche Maßnahmen.

Grüße Matthias

[Cybergreek]

Die Idee finde ich auch interessant und bin gespannt auf Deine Test-Ergebnisse Rizzo

Jetzt, wo Bruecksen das nochmal anders formuliert hat, ist mir auch eingefallen, woher ich sowas kenne. Bei http://spotlight.de/ läuft das Schreiben eines Postings auch so ab, dass man gezwungen wird sich die Vorschau anzuschauen. Ich war da länger nicht mehr drauf, aber ich habe früher da selten Spam gesehen.

[phpBuddy]

Ich war da länger nicht mehr drauf ...

Ich war dort noch nie drauf.

Aber cool das es solche Ansätze schon gibt, dann scheint die Idee ja nicht ganz so abwegig zu sein. Müsste man nur noch wissen wie effektiv es sich bei denen auswirkt. Benutzerfreundlicher als CAPTCHA oder Email Validierung ist es aber wohl allemal. hmmm ...


Danke für Eure bisherigen Antworten!

[Adromir]

Die Idee finde ich interessant. Ich hatte mal den Vorschlag gehört, einfach eine Vorschauseite zwischenzuschalten und erst beim Klick auf "Weiter" werden die Daten eingetragen. Ist ja ziemlich das gleiche System, nur noch mit einer zusätzlichen Überprüfung.
Ich denke, in Verbindung mit der Reaktionszeit (Formular, Link schneller als 5 Sek. oder so geklickt), könnte das schon ne gute Hürde darstellen.

[phpBuddy]

*malwiederausbuddeln*

Gerade eben kam mir noch 'ne Idee, wie man den Spambots das Leben schwerer machen kann. Das ist zwar nicht wirklich barrierearm, aber vielleicht dennoch eine Überlegung wert.

Beim darüber nachdenken fiel mir auf, dass eigentlich alle CAPTCHAs, die mir bisher begegnet sind, als normale Grafik im Image-Tag eingebunden waren. Bots erkennen das mittlerweile ja immer öfter und knacken die Grafiken teilweise selbst, teilweise binden sie die Grafiken mit dem Code auf speziellen Seiten ein, um sie dort von echten Menschen (unwissentlich) knacken zu lassen.
Als Gegenmassnahme, damit Bots die Grafik nicht entziffern können, werden wilde Hintergründe, verbogene Schriftarten und sonstiges eingesetzt. Das erschwert aber auch dem Mensch den Code auf Anhieb zu lesen. Jetzt frage ich mich, wieso das eigentlich so sein muß?

Was wäre denn, wenn man einen Sicherheitscode beim betreten der Seite generiert, aber nicht wie üblich ein IMG-Tag im Formular einbindet, sondern man die Grafik mit dem gut lesbaren Code als Hintergrundbild eines x-beliebigen Div (z.B. #footer-minibanner) einbindet und diesen Container per CSS über das Formular legt, dorthin wo das CAPTCHA sonst stehen würde. Natürlich muß man sich da etwas Platz schaffen, damit man nichts vom Formular unzugänglich macht. Dadurch wäre die CAPTCHA Grafik für Bots nicht als solche zu erkennen, weil es ja scheinbar nur ein Hintergrund eines Footer-Divs ist, der Benutzer aber den Code ganz normal sehen würde.
Man könnte den Code auch als Hintergrundbild des Formulars einbinden (z.B. Senkrechtschrift in dezenter Farbe, damit es nicht stört, rechts von den Feldern) mit dem Hinweis, "bitte den Code rechts neben den Feldern eingeben". So könnte man auch sehr große Schrift benutzen, die leicht zu lesen ist und die Leute müssten sich keine Knoten in die Augen machen, um den Code zu entziffern.

Hat das schon mal jemand probiert oder auf einer Seite gesehen?

[Boris]

Auf die einfachsten und besten Ideen kommt man nicht ... deine Idee ist genial! Ich denke wir sollten diesen NG-CSS-Captcha entwickeln

[Jokai olvaso]

Paßt vielleicht ganz gut in diesen Thread hier: Bin vor kurzem auf folgende Captcha-Variante gestoßen und bin jetzt am grübeln, ob das irgendwelche negativen Konsequenzen für Besucher oder Suchmaschinen haben könnte:

Man fügt dem zu schützenden Formular ein weiteres Feld mit aussagekräftigem Namen (z.B. URL-Link) hinzu, versteckt dies aber per CSS (z.B. absolute Positionierung außerhalb des sichtbaren Bereichs). Ergo sieht ein normaler Benutzer das Feld nicht, und kann es nicht ausfüllen. Ein Bot würde das Feld aber wohl trotzdem ausfüllen. Daher die gesendeten Formular-Daten überprüfen ob das Feld ausgefüllt ist, und falls ja: Daten verwerfen.

Einziges Problem das ich hierbei sehe: Besucher mit Screenreadern würden das Feld auch sehen, daher wäre wohl ein Hinweis ("Dieses Feld nicht ausfüllen!") notwendig. Den könnte man ja analog zum Eingabefeld mit CSS für die Masse der Besucher verstecken.

Hat jemand mit dieser Methode erfahren bzw. sieht da irgendwelchen offensichtlichen Problemen, die mir entgangen sind?