eine Wikimedia-Erweiterung die Bots aussperren will, arbeitet mit unsichtbaren Feldern. Du baust also weitere Input-Felder ein, die du mit Hilfe von CSS ausblendest. Im HTML-Code stehen die trotzdem drin. Wenn die dann so schön aussagekräftige Namen haben wie EMail, dann tragen da Bots auch was ein, der normale User aber nicht, weil er das Feld nicht sieht. Schon hast du eine ganz einfache Unterscheidung zwischen Bot und Mensch, die sogar ohne Javascript auskommt. Nur die Kommandozeilenbrowser-Benutzer könnten sich verarscht vorkommen. Aber bitte: Wer verwendet heutzutage in Zeiten von IE (fast) 9, Firefox (fast) 4 und Google Crome 2 noch einen Browser der kein CSS drauf hat?

Bernhard

Zitat von rollstuhlfahrer:

Wer verwendet heutzutage in Zeiten von IE (fast) 9, Firefox (fast) 4 und Google Crome 2 noch einen Browser der kein CSS drauf hat?

Einige Leute, die sehbehindert sind und somit auf barrierefreie Websiten angewiesen sind. Zugegeben, meine ist es seit den JS-Formularen auch nicht mehr ganz ...

Aber die Idee ist ganz nett.

Zitat von Matze:

Einige Leute, die sehbehindert sind und somit auf barrierefreie Websiten angewiesen sind.

Wobei das display-Attribut in CSS ja sicher auch von einem für Blinde geeigneten Browser interpretiert würde ...

Äh danke erstmal. Habe ich das nun richtig verstanden, dass du lediglich die ID verschleierst, dich aber nicht wirklich gegen Bots schützt? Der Bot weiß nun anhand der ID nicht, was in welches Feld gehört, da anstelle von "email" nun "x_..." da steht, mehr nicht.

Aber das Formular können Bots dennoch absenden und durch Probieren auch korrekte Einträge machen.

Was gut gegen Bots hilft ist eine Mindestzeit zu definieren, die zwischen Aufruf und Absen des des Formulars vergehen muss.
Setzt man das auf 5 Sekunden, kommt kein Bots durch, zumindest war's bei mir so. Bots senden die nämlich normalerweise in < 1 Sekunde ab bzw. senden die Postdaten direkt.

Zitat von Matze:

Äh danke erstmal. Habe ich das nun richtig verstanden, dass du lediglich die ID verschleierst, dich aber nicht wirklich gegen Bots schützt? Der Bot weiß nun anhand der ID nicht, was in welches Feld gehört, da anstelle von "email" nun "x_..." da steht, mehr nicht.

So ist das, ja.

Zitat von Matze:

Aber das Formular können Bots dennoch absenden und durch Probieren auch korrekte Einträge machen.

Scheinen sie aber nicht zu tun. Aber meine Methode kann man ja auch auf anderes als auf die Anmeldeformulare ausdehnen. Dann wird es auch nochmal schwerer. Außerdem kann ich ohne CAPTCHA auch die Anzahl der Anmeldeversuche innerhalb einer gewissen Zeit beschränken

Zitat von Matze:

Was gut gegen Bots hilft ist eine Mindestzeit zu definieren, die zwischen Aufruf und Absen des des Formulars vergehen muss.

Aaah, danke. Das ist mal ein Tip den ich noch implementieren werde.

Zitat von Matze:

Setzt man das auf 5 Sekunden, kommt kein Bots durch, zumindest war's bei mir so. Bots senden die nämlich normalerweise in < 1 Sekunde ab bzw. senden die Postdaten direkt.

OK.

@Assarbad: wenn du dann noch eine Mapping-Tabelle erstellst in der du fuer eine bestimmte session_id die Zuordnungen der Formularfelder (Originalname => salted) speicherst dann kannst du auch auf einen Algorithmus setzen, der bei jedem Aufruf einen neuen zufaelligen Namen generiert. So bist du nur noch von der Session abhaengig und der "verschluesselte" Name kann nicht mehr zuverlaessig berechnet werden.

Greetz
alcaeus

Zitat von alcaeus:

@Assarbad: wenn du dann noch eine Mapping-Tabelle erstellst in der du fuer eine bestimmte session_id die Zuordnungen der Formularfelder (Originalname => salted) speicherst dann kannst du auch auf einen Algorithmus setzen, der bei jedem Aufruf einen neuen zufaelligen Namen generiert. So bist du nur noch von der Session abhaengig und der "verschluesselte" Name kann nicht mehr zuverlaessig berechnet werden.

Die session_id in den Wert einfließen zu lassen ist keinerlei Problem. Eine Zuordnung sollte sich auch ohne Tabelle ergeben - zumal, wie willst du die Tabelle von dem einen PHP-Skript in das nächste herbüberretten? Via Datenbank? Das halte ich eher für Overkill. Die Praxis hat bewiesen, daß eine Zuordnung nach IP ausreicht. Allerdings könnte man es vielleicht in abgewandelter Form machen. Statt der einzelnen Zuordnungen, wird wiederum nur ein Geheimnis pro Sitzung erstellt und mit in der Sitzungstabelle (die schon existiert) gespeichert. So kann man wiederum auf beiden Seiten alles berechnen, ohne daß komplizierte Datenbankoperationen notwendig werden.

Dank des Salts ist auch jetzt schon keine zuverlässige Berechnung der Namen für Außenstehende möglich, es sei denn sie kennen das Geheimnis (i.e. saltkey). Würde man den oben gezeigten Code weiterhin so modifizieren, daß man den Vorschlag mit der Zeit einfließen lassen würde, könnte man das Formular sogar anhand des aktuellen Datums oder der aktuellen Zeit "salzen" (also immer intervallweise). Dadurch gäbe es keine Brüche wann immer der Tag endet oder eine Stunde wechselt. Alle die länger als das Intervall mit dem Ausfüllen warten, haben allerdings ein Problem

Aber coole Idee. Werde mir das alles mal notieren. Vielleicht mache ich daraus ja mal eine Erweiterung, statt es nur im VCS zu pflegen