Barrierefreiheit vs. Captcha - Druckversion +- PHP Rocks (https://www.php-rocks.de) +-- Forum: Board Gebrabbel (https://www.php-rocks.de/https://www.php-rocks.de/forum/22-board-gebrabbel.html) +--- Forum: Off Topic (https://www.php-rocks.de/https://www.php-rocks.de/forum/26-off-topic.html) +--- Thema: Barrierefreiheit vs. Captcha (/https://www.php-rocks.de/thema/108-re-barrierefreiheit-vs-captcha.html) Seiten:
1
2
|
Barrierefreiheit vs. Captcha - Till - 16.08.2016 Hallo, habe mal eine Frage wie Ihr das seht? Ist dieses Captcha (siehe Anhang) eine Überforderung? Abgesehen davon das ich noch Audio für Blinde einführen MUß/sollte? Ich frage deshalb, weil es schon von Spammern durchdrungen wurde ( so schwer ist es nun wirklich nicht, damit habe ich gerechnet), es ist nur so: Ein(e) User(In) dachte sie müßte, bspw. im hier geposterten Captcha D5 eintippen. Und sie ist eine von den netten Usern, welche mich auf Fehler hinweisen. Leider habe ich am captcha seit dem noch nichts geändert. Was das betrifft (usabillity) bin ich einfallslos!? Wie sieht Euer Captcha aus? RE: Barrierefreiheit vs. Captcha - Till - 17.08.2016 Ich hab noch so ein fragwürdiges Captcha (siehe Anhang). RE: Barrierefreiheit vs. Captcha - Arne Drews - 18.08.2016 Hi Till, Ich verwende aus drei Gründen gar keine Captchas:
Gruß Arne RE: Barrierefreiheit vs. Captcha - Till - 20.08.2016 Code: Es gibt ausreichend Alternativen, die Captchas in den meisten Fällen überflüssig lassen werden. Mir würde bspw. als erstes einfallen, per $_SESSION zu checken, ob der User vor dem Absenden des Formulares selbiges auch besucht hat. Javascript vorraussetzen. Was gibt es noch, konkret? RE: Barrierefreiheit vs. Captcha - Arne Drews - 20.08.2016 Es gibt da natürlich viele verschiedene Ansichten, aber ich betreue bspw. einige Ferienwohnungen, die alle ein Formular zur Buchungsanfrage verwenden. Ich verlasse mich hauptsächlich auf drei Verfahren:
Das Schöne ist, dass ich bspw. beim TimeProcessing-Verfahren über die statischen Zeitwerte und den Toleranzen die Filterung verschärfen oder abschwächen kann, je nachdem, wie es gewünscht ist. Die meisten von meinem System erkannten Bots werden über dieses Verfahren gefiltert. Auch mit dem Honeypot-Verfahren bin ich an sich zufrieden, fallen auch Bots durch dieses Raster. Es wird sicher noch ne Menge Alternativen geben, da müsste man mal nach Captcha Alternativen googlen. Ich zumindest komme sehr gut ohne aus... RE: Barrierefreiheit vs. Captcha - Till - 20.08.2016 Zitat:2. HoneypotDazu muß der Bot erstmal auf dieses Feld hereinfallen/das Formular spidern(, ich denke nur wenige Bots "füllen das Formular aus", die meisten machen einen POST ohne Bezug zu irgendwelchen Formularfeldern, nagut nicht die meisten aber einige ?) Zitat:3. TimeProcessingErfüllt auch nur einen Case (in welchem das Formular "zu früh" abgesendet wird), aber immerhin. Zitat:1. Transactionnumberdas geht ungefähr in meine Richtung: Wenn ich die TAN (oder einen Salt/Hash ) in der Session speichere kann ich vermeiden das ein Bot das hidden field ausliest? Je nach Formular sollte man ggf. spezifisch validieren (so werden bei mir IPs mit x false Logins gebklockt bspw.)...? OK, ich habe nun folgendes "Workaround" in Angriff genommen (bisher beim oberen Captcha): - Ich lasse das Captcha wie gehabt anzeigen und verlange Validierung. - Ich sende einen Request zu einer Script Injection ab, das Script füllt das Captcha richtig aus und verbirgt es So muß ich möglichst wenig an bestehendem ändern und habe einen gewissen minimalen Schutz vor Spam, im besten Fall bemerkt der User gar kein Captcha? Wenn nun ein Bot aber mein javascript interpretiert, kann er das Forumlar absenden? Um den "Session Check"/"Transactionnumber" zu umgehen muß der Bot nur vor dem POST das Formular besuchen und seinen Session Cookie merken? RE: Barrierefreiheit vs. Captcha - Arne Drews - 20.08.2016 Zitat:Dazu muß der Bot erstmal auf dieses Feld hereinfallen/das Formular spidern(, ich denke nur wenige Bots "füllen das Formular aus", die meisten machen einen POST ohne Bezug zu irgendwelchen Formularfeldern, nagut nicht die meisten aber einige ?)Es gibt ausreichend Bots, die Formularfelder aus dem Quelltext lesen und entsprechend "ausfüllen". Woher sollten sie sonst auch wissen, welche Felder im POST erwartet werden. Mit "ausfüllen" ist natürlich gemeint, dass sie einen entsprechenden mit POST-Daten gefüllten Request senden... Zitat:Erfüllt auch nur einen Case (in welchem das Formular "zu früh" abgesendet wird), aber immerhin.Nein, zu früh und zu spät wird gefiltert! Ausserdem habe ich wie gesagt die Möglichkeit, das Zeitfenster enger oder breiter zu machen, um besser eingrenzen zu können. Denn es gibt Bots, die ein Formular zeitverzögert absenden, um einen menschlichen User vorzutäuschen. Zitat:das geht ungefähr in meine Richtung: Wenn ich die TAN (oder einen Salt/Hash ) in der Session speichere kann ich vermeiden das ein Bot das hidden field ausliest?Da denke ich müssten andere Bots beteiligt sein. Ein Bot, der Formulare spammt, wird keine Sessions hijacken, glaube ich. Allerdings speichere ich die TANs nicht in Sessions, sondern Dateien oder Datenbanken. Zitat:Je nach Formular sollte man ggf. spezifisch validieren (so werden bei mir IPs mit x false Logins gebklockt bspw.)...?Mag auch ne Variante sein, aber ich halte mich vom IP Handling immer etwas fern, da diese nicht immer eindeutig sind. Zitat:Um den "Session Check"/"Transactionnumber" zu umgehen muß der Bot nur vor dem POST das Formular besuchen und seinen Session Cookie merken?Wie gesagt, ich mache das nicht über die Session. Aber ja, natürlich sendet der Bot in dem Fall die korrekte TAN mit, aber dann greifen halt andere Mechanismen. Du wirst nie ein Formular schützen können mit nur einem Schutzfaktor. Aber mehrere kombiniert funktioniert sehr gut. Das TimeProcessing erreicht bei mir immer die höchste Quote, aber die anderen filtern halt auch was. Nur mal aus der Luft gegriffen: 50% + 15% + 5% wären immerhin 70% Erfolgsquote... Zitat:OK, ich habe nun folgendes "Workaround" in Angriff genommen (bisher beim oberen Captcha):Und wo siehst Du da Deine Vorteile? RE: Barrierefreiheit vs. Captcha - Till - 20.08.2016 Zitat:Und wo siehst Du da Deine Vorteile?Zunächst einmal nur das das Captcha zentral (für den User scheinbar) deaktiviert ist, ohne das ich alle Formulare/anderen Code überall ändern muß! Darüber hinaus bleibt ein minimaler Schutz bestehen, der Bot muß zumindest das Formular besuchen (vor einem POST) und das javascript evaluieren. Zitat:Allerdings speichere ich die TANs nicht in Sessions, sondern Dateien oder Datenbanken.Im Detail irrelevant, es geht nur darum das die TAN Serverseitig gespeichert ist, mit Session kannst Du sie leicht einem UserAgent zuordnen. Zitat:Es gibt ausreichend Bots, die Formularfelder aus dem Quelltext lesen und entsprechend "ausfüllen". Woher sollten sie sonst auch wissen, welche Felder im POST erwartet werden. Mit "ausfüllen" ist natürlich gemeint, dass sie einen entsprechenden mit POST-Daten gefüllten Request senden...Die meisten Bots posten aber den Request ohne JEWEILS vorher das Formular (welches die TAN generiert) besucht zu haben, dabei "vermuten" sie oft irgendwelche Formularfelder, oder benutzen welche sie vorher in Deinem Formular ausgelesen haben. Zitat:Da denke ich müssten andere Bots beteiligt sein. Ein Bot, der Formulare spammt, wird keine Sessions hijacken, glaube ich. Allerdings speichere ich die TANs nicht in Sessions, sondern Dateien oder Datenbanken.Das meine ich nicht (hijacken), ich meine nur, wenn Du die TAN in einem hidden field anzeigst, kann der BOT sie auch auslesen und das Formular entsprechend absenden. Zitat:Mag auch ne Variante sein, aber ich halte mich vom IP Handling immer etwas fern, da diese nicht immer eindeutig sind.Mag sein, ich rede hier davon verhaltensauffällige IPs zu erkennen und (eine gewisse Zeit) zu blockieren. Zitat:TimeProcessingDas überzeugt mich irgendwie nicht wirklich, schliesslich kann der User nur z.B. ein Formularfeld z.B. mit 3 Buchstaben ausgefüllt, dafür aber eine Stunde nachgedacht haben? RE: Barrierefreiheit vs. Captcha - Till - 20.08.2016 Nochmal zu TimeProcessing: Was mich eher überzeugen würde, wäre die Keypress-Events zu zählen und die Anzahl im Formular mitzusenden und mit dem gesendeten Text zu vergleichen, aber mh...ich weiß nicht?! Man müßte gelöschte Zeichen berücksichtigen und hassenichgesehen... RE: Barrierefreiheit vs. Captcha - Arne Drews - 21.08.2016 Zitat:Das meine ich nicht (hijacken), ich meine nur, wenn Du die TAN in einem hidden field anzeigst, kann der BOT sie auch auslesen und das Formular entsprechend absenden.Ja, aber nur einmal! Ohne diesen Mechanismus kann ein Bot den Request zigfach abfeuern. Bis auf den einen werden die anderen alle schonmal gefiltert! Du betrachtest immer nur einen spezifischen Punkt des ganzen und nicht das drum herum... Zitat:Im Detail irrelevant, es geht nur darum das die TAN Serverseitig gespeichert ist, mit Session kannst Du sie leicht einem UserAgent zuordnen.Vielleicht meinen wir beide etwas anderes, wenn wir von Sessions reden? Solange ich die TAN nicht in einer Session speichere, wie soll die dann über eine Session zugeordnet werden können?! Zitat:Die meisten Bots posten aber den Request ohne JEWEILS vorher das Formular (welches die TAN generiert) besucht zu haben, dabei "vermuten" sie oft irgendwelche Formularfelder, oder benutzen welche sie vorher in Deinem Formular ausgelesen haben.Ja, und Bots sind auch nicht "dumm", klar lesen die Formulare aus, um die gängigsten Feldnamen zu berechnen. Genau deswegen füllen die ja das Textfeld aus und geben sich als Bot zu erkennen. Das ist der Sinn des Honeypot... Zitat:Das überzeugt mich irgendwie nicht wirklich, schliesslich kann der User nur z.B. ein Formularfeld z.B. mit 3 Buchstaben ausgefüllt, dafür aber eine Stunde nachgedacht haben?Ja und? Der muß das Formular dann halt noch einmal ausfüllen. Da gehe ich lieber den sichereren Weg, als wieder alles zum Wohlgefallen der Usability zu öffnen. Glaub mir, mit den richtigen Toleranzen funktioniert das ganz gut... Zitat:Was mich eher überzeugen würde, wäre die Keypress-Events zu zählen und die Anzahl im Formular mitzusenden und mit dem gesendeten Text zu vergleichen, aber mh...ich weiß nicht?! Man müßte gelöschte Zeichen berücksichtigen und hassenichgesehen...Das Problem ist, dass wir nicht ganz von der selben Sache sprechen. Du redest nur von JS, ich ausschliesslich von serverseitig ( bspw. PHP ). JS schön und gut, aber ich kontrolliere Usereingaben doch primär gerne serverseitig. Wenn JS zur Verfügung steht kann man prima damit schon Vor-Validieren, aber am Ende traue ich der clientseitigen Geschichte eher weniger... |