PHP rocks! wünscht allen Mitgliedern einen guten Rutsch ins neue Jahr 2017 !!!
Hinweis: Das Forum zieht um! Um keine Datenverluste zu haben, schalten wir zwecks Übernahme der Daten das Forum am Sonntag, den 24.04.2016 um ca. 21:00 Uhr offline und passen anschliessend die DNS-Einträge an.
www.php-rocks.de wird euch dann nach den Aktualisierungen der DNS-Server wieder wie gewohnt uneingeschränkt zur Verfügung stehen.
Danke für euer Verständnis!

Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Barrierefreiheit vs. Captcha
#1
Shocked 
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?


Angehängte Dateien Thumbnail(s)
   
Antworten
#2
Ich hab noch so ein fragwürdiges Captcha (siehe Anhang).


Angehängte Dateien Thumbnail(s)
   
Antworten
#3
Hi Till,

Ich verwende aus drei Gründen gar keine Captchas:
  1. Captchas empfinde ich als Widerspruch zur Usability
  2. Die "besten" Captchas, die von Bots nicht "errechnet" oder gelesen werden können, sind vom menschlichen User auch schwer zu "entziffern"
  3. Es gibt ausreichend Alternativen, die Captchas in den meisten Fällen überflüssig lassen werden.

Gruß Arne
Antworten
#4
Code:
Es gibt ausreichend Alternativen, die Captchas in den meisten Fällen überflüssig lassen werden.
Kannst Du vielleicht ein paar Beispiele aufzeigen/verlinken?

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?
Antworten
#5
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:
  1. Transactionnumber
    Ich generiere beim Aufruf der Formularseite eine TAN, die ich mit mir vorliegenden Daten zusammen speichere und auch in einem Hidden-Feld des Formulars hinterlege.
    Die TAN aus dem Formular vergleiche ich dann mit der gespeicherten.
  2. Honeypot
    Obwohl dieses Verfahren umstritten ist ( zumindest meinen viele das bringt nichts ), ist das fester Bestandteil meiner Formulare. Dazu hinterlege ich einfach ein Textfeld mit einem scheinbar wichtigen Namen wie etwa "emailconfirm" o.ä. und blende das per CSS aus. Dieses Feld muß bei der Formularprüfung leer sein, weil kein normaler User das ausgefüllt haben könnte.
  3. TimeProcessing ( nenne ich zumindest so )
    Jedes Eingabe-Element hat bei mir einen vordefinierten statischen Zeitwert, der sich auf das normale Handling von Formular-Feldern bezieht. Nach dem Absenden zähle ich die Zeichen pro Eingabefeld und berechne auf Basis eines angenommenen Mittelwertes der Anschläge pro Minute des Users eine Zeit, in der das Formular hätte ausgefüllt werden können. Diesem Wert gebe ich noch eine Toleranz in beide Richtungen, so dass ich ein Zeitfenster habe, in dem das Formular nach dem Aufruf ausgefüllt und abgesendet worden sein muß.
Das sind die hauptsächlichen Verfahren, die ich grundsätzlich in meine Formulare einbaue.
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...
Tongue
Antworten
#6
Zitat:2. Honeypot
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 ?)

Zitat:3. TimeProcessing
Erfüllt auch nur einen Case (in welchem das Formular "zu früh" abgesendet wird), aber immerhin.

Zitat:1. Transactionnumber
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?

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?
Antworten
#7
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):
- 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
Und wo siehst Du da Deine Vorteile?
Antworten
#8
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:TimeProcessing
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?
Antworten
#9
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...
Antworten
#10
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...
Antworten


Gehe zu: