Zitat: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...Durchaus NEIN: Die ganze Validierung des Captchas erfolgt (bei mir z.B.) serverseitig.
Mein obiger Vorschlag soll lediglich per js die keyevents in ein Formularfeld schreiben, welches dann SERVERSEITIG mit dem Text aus den übrigen Formularfeldern verglichen werdebn kann.
Dies ist aber nur eine spontane Idee gewesen, auch hier kann der Bot die benötigten KeyEvents für den Text abschätzen...
Zitat:Du betrachtest immer nur einen spezifischen Punkt des ganzen und nicht das drum herum...Wieder NEIN: Ich (bzw. meine Seiten) zieht möglichst alle Fälle in Betracht, bei dem von Dir/mir zitierten Beispiel gehe ich vom worst case aus: Der UserAgent "simluiert" einen "echten" Benutzer, d.h. er requested erst das Formular (wartet ggf. eine menschenmögliche Zeit) und sendet DANN den post entsprechend ab, und das schlimmstenfalls VOR jedem Request.
Zitat:Ja und? Der muß das Formular dann halt noch einmal ausfüllenWieder NEIN (imho): Ich habe bspw. Formulare für ganze (HTML-)Artikel, vor diesen könnte ein User wenige Minuten oder auch einen ganzen Tag oder länger sitzen, ich möchte ihm nicht zumuten das Formular nochmal auszufüllen oder beim Ausfüllen unter Zeitdruck zu geraten!
Zitat: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?!Eben drum!
Alternativ statt einer session könnte ein gesalzener Hash/Checksumme erstellt werden.
Zitat:Vielleicht meinen wir beide etwas anderesBei mir funktioniert das (TAN oder wie auch immer) ungefähr so:
Beim Aufruf des Formulares wird ein TAN erstellt, ein entsprechender key wird in einem hidden feld gespeichert, beim response wird die TAN entsprechend validiert, sei es durch einen Abgleich mit der Session oder einem Prüfsummenverfahren (letzteres benötigt kein Speichern der Daten serverseitig).
Dies soll zunächst allein dazu dienen zu prüfen ob der UserAgent vor dem post das Formular auch requested/"gesehen" hat.
Zitat: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...Auch wieder jein, bots sind i.d.R. dumm und es gibt eine Reihe welche einfach gängige Formularfelder (z.B. irgendwelcher CMS, oder "user", "pass") durchprobieren, und, gesetzt den Fall der Bot ist nicht dumm so wird er womöglich das Formular vorher untersucht haben und wissen welche Felder honeypots sind.
