Mülltonne für alte CAPTCHA-/ Spamflut-Daten

[mod]

Hallo,

ich habe vor einem Monat an einem CAPTCHA-/ Spamflutsperrsystem gearbeitet. Captcha-Strings und Flutsperrzeitem speichere ich mit der Session-ID in DB-Tabellen.

Meine Frage: Wie kann man effizienz alte, d.h. nicht mehr gültige Daten entfernen. Bei Users ist dies möglich wenn sie sich erfolgreich ausloggen bzw. erfolgreich einloggen. Wie könnte man das bei Gästen bewerkstelligen?

Habt ihre andere Vorschläge?

Gruß mod.

[Felix Riesterer]

Lieber mod,

auch wenn einige hier im Forum das anders sehen, finde ich Captchas immer schlecht. Es geht definitiv auch anders, ohne dass man menschliche Besucher nervt.

In meinem GB-Script findest Du z.B. kein Captcha, SPAM ist für mich aber trotzdem kein Thema. Wenn Du willst, kannst Du Dir die verwendete Technik ja anschauen. Hier im Forum gibt es genügend Threads, die sich mit Alternativen zu Captchas auseinandersetzen.

Liebe Grüße,

Felix Riesterer.

[mod]

Hallo Felix

In meinem GB-Script findest Du z.B. kein Captcha, SPAM ist für mich aber trotzdem kein Thema. Wenn Du willst, kannst Du Dir die verwendete Technik ja anschauen. Hier im Forum gibt es genügend Threads, die sich mit Alternativen zu Captchas auseinandersetzen.

Erzwungene Vorschau ... hmm ... gute Idee.

[Felix Riesterer]

Lieber mod,

Erzwungene Vorschau ... hmm ... gute Idee.

das ist nicht das einzige Element in diesem Zusammenhang!

Liebe Grüße,

Felix Riesterer.

[mod]

Hallo Felix

das ist nicht das einzige Element in diesem Zusammenhang!

Aus deinem GB-Script: gb.script.inc

  
				// create special input fields (type=hidden) with session-based random values to block SPAM bots  
				if (!$GLOBALS['gb-script']['settings']['admin-mode']) {  
					$GLOBALS['gb-script']['output'] .= "</div>\n".'<div id="sig">'."\n";  
					// special anti SPAM values  
					srand ((double)microtime()*1000000); // create random number  
					// create random letter so random values are between A1000 and Z9999  
					$_SESSION['for-gb-script']['key'] = chr(rand(65, 65+25)).rand(1000, 9999);  
					$_SESSION['for-gb-script']['lock'] = chr(rand(65, 65+25)).rand(1000, 9999);  
					// remember timestamp  
					$_SESSION['for-gb-script']['timestamp'] = time();  

Verstehe ich nicht ?!

Gruß mod.

[Felix Riesterer]

Lieber mod,

ich speichere in der Session zwei Werte wie z.B. A103 und F399, welche im Formular als name-value-Paar enthalten sein müssen (z.B. <input type="hidden" name="A103" value="F399" />), damit das Posting akzeptiert wird. Fehlt das Paar oder passt es einfach nicht, erscheint wieder die Vorschau.

Der Admin darf auch so posten, denn er habt sich ja eingelogged.

Liebe Grüße,

Felix Riesterer.

[mod]

Hallo Felix

ich speichere in der Session zwei Werte wie z.B. A103 und F399, welche im Formular als name-value-Paar enthalten sein müssen (z.B. <input type="hidden" name="A103" value="F399" />), damit das Posting akzeptiert wird. Fehlt das Paar oder passt es einfach nicht, erscheint wieder die Vorschau.

Ich verstehe den Sinn dahinter nicht so richtig! Der Bot kann doch so lange warten, bis er sich im Zeitfenster befindet und dann das Formular abschicken - da nützt dann auch nicht mehr das zufällige Paar nicht mehr ?!

Gruß mod.

[Felix Riesterer]

Lieber mod,

Ich verstehe den Sinn dahinter nicht so richtig! Der Bot kann doch so lange warten, bis er sich im Zeitfenster befindet und dann das Formular abschicken - da nützt dann auch nicht mehr das zufällige Paar nicht mehr ?!

ja, das kann er. Aber dazu müsste er sich wie ein Besucher mit Browser verhalten, brav meine Seite mit dem Formular aufrufen und dabei eine Session annehmen, das Formular ausfüllen und abschicken, die paar Sekunden warten und dann die Vorschau bestätigen.

Üblicherweise kopieren sich die Bots nur das Formular, um es dann zu speichern und später auszufüllen. Gerne auch mehrmals über die Tage verteilt. Und genau hier scheitern sie daran, dass zu meinem Formular eine Session gehört, deren ID im Formular steht (ähnlich wie bei hotti), an die aber sekundäre Daten geknüpft werden, die bei jedem Aufruf der Seite (lies "des Formulars") geändert werden - ähnlich wie bei hotti. Und das Ganze natürlich in einem für Menschen sinnvollen Zeitfenster.

Meine (fehlenden) Erfahrungen mit automatisiertem SPAM bestätigen jedenfalls die Wirksamkeit. Sonst hätte ich da längst ein CAPTCHA eingebastelt - wenn ich von dessen Wirksamkeit überzeugt wäre. Aber meiner Meinung nach nervt das den echten Besucher nur. Ob Captchas wirklich helfen, will ich nicht beurteilen, dass sie den menschlichen Besucher nerven, das will ich dagegen betonen.

Liebe Grüße,

Felix Riesterer.

[Mitleser]

Meine (fehlenden) Erfahrungen mit automatisiertem SPAM bestätigen jedenfalls die Wirksamkeit. Sonst hätte ich da längst ein CAPTCHA eingebastelt - wenn ich von dessen Wirksamkeit überzeugt wäre. Aber meiner Meinung nach nervt das den echten Besucher nur. Ob Captchas wirklich helfen, will ich nicht beurteilen, dass sie den menschlichen Besucher nerven, das will ich dagegen betonen.

Wenn Du eine wirksame Alternative am Start hast, wirst Du sehr schnell sehr reich werden. Für 99% der Formulare im Web gibt es aber freilich nettere Lösungen. Bis auf diejenigen hier, die für Webmail, Social Communities o.ä. tätig sind, stellt sich die Frage nicht.

[Felix Riesterer]

Lieber Mitleser,

Wenn Du eine wirksame Alternative am Start hast, wirst Du sehr schnell sehr reich werden.

huh? Wozu? Ich will nicht reich werden, ich will nur automatisierten SPAM bei mir verhindern.

Für 99% der Formulare im Web gibt es aber freilich nettere Lösungen.

Genau, das mit dem "nett" war ja gerade mein Kernanliegen.

Bis auf diejenigen hier, die für Webmail, Social Communities o.ä. tätig sind, stellt sich die Frage nicht.

Wieso? Gerade bei Webmail und Social Communities muss man sich doch einloggen und ersetzt damit die Notwendigkeit für ein Captcha! Und Brute-force-Attacken kann man mit "dreimal, danach Zwangspause" beantworten, die sich um jeden "drängelnden" Versuch automatisch verlängert.

Wo braucht es da ein Captcha?

Diese Undinger werden doch in der Regel dort eingesetzt, wo gerade keine Anmeldung notwendig ist, wo "einfach nur so" Content angenommern wird (wie z.B. bei Blog-Kommentaren oder Gästebüchern), wo man aber Bots aussperren will, um ein Zumüllen zu verhindern. Wieso sollte man sich gerade da (also nicht bei Webmail und Social Communities) nicht die Captcha-Frage stellen?

Liebe Grüße,

Felix Riesterer.

[Mitleser]

huh? Wozu? Ich will nicht reich werden, ich will nur automatisierten SPAM bei mir verhindern.

Das sollte nur ein dezenter Hinweis sein, dass es oftmals einen Grund hat, warum Captchas zum Einsatz kommen :-)

Wieso? Gerade bei Webmail und Social Communities muss man sich doch einloggen und ersetzt damit die Notwendigkeit für ein Captcha!

Um sich einzuloggen, muss man sich gewöhnlich registrieren -> Captcha.

Diese Undinger werden doch in der Regel dort eingesetzt, wo gerade keine Anmeldung notwendig ist, wo "einfach nur so" Content angenommern wird (wie z.B. bei Blog-Kommentaren oder Gästebüchern), wo man aber Bots aussperren will, um ein Zumüllen zu verhindern. Wieso sollte man sich gerade da (also nicht bei Webmail und Social Communities) nicht die Captcha-Frage stellen?

Sofern es die "Attraktivität" der Seite hergibt, reicht die nette Lösung sicherlich. Hochfrequentierte benötigen ein Captcha. Alternativ auch manuelle Freischaltung des "Kommentars".

[Matthias Apsel]

Om nah hoo pez nyeetz, Mitleser!

Hochfrequentierte benötigen ein Captcha,

um menschliche Besucher zu vergraulen.

Matthias

[Mitleser]

Hochfrequentierte benötigen ein Captcha,
um menschliche Besucher zu vergraulen.

Leider ist das ein unbestrittener Nachteil, den man aber bereit ist in Kauf zu nehmen, um das eigentliche Ziel zu erreichen: Bots aussperren.

Ich wiederhole mich: Wer auch immer eine nette und gleichzeitig nicht "scriptbare" Alternative aus dem Hut zaubert, hat ausgesorgt - für viele Generationen.

[mod]

Ich habe noch andere Maßnahmen gefunden:

• Hidden-Feld mit CSS ... keine gute Idee.
• Zeitsperre ... habe ich schon
• CAPTCHA ... habe ich schon

@hotti: erzähl mal über deine Idee einen Post mit einer ID zu versehen?

Gibt's noch andere Maßnahmen ??

[hotti]

h1,

@hotti: erzähl mal über deine Idee einen Post mit einer ID zu versehen?

Hehe, @hotti ist gefragt ;)

Von PHP habe ich üüüüberhaupt keine Ahnung, nurmalso nebendran...

Also, die Idee mit der ID/Zeitfenster:

Die ID muss eindeutig sein, schaffe oder besorge Dir eine entsprechende Funktion, die das kann, Du kriegst dann sowas:

fd5b7b25c9c5cd0c31e855ef6d9c7b14

Diese ID wird bei der Ausgabe des Formulars in ein Hidden-Field gelegt, neues Formular => neue ID.

Gleichzeitig wird diese ID serverseitig mit einem Zeitstempel versehen und gespeichert (Tabelle mit zwei Spalten).

Beim Submit kommt die ID mit, damit wird geprüft:

1. Gibt es die ID in der serverseitigen Tabelle?
2. Sind seit der Erzeugung ein paar Sekunden verstrichen?

Wenn 1) und 2) erfüllt sind, wir der Kram eingetragen und die ID gelöscht. Unbenutzte IDs werden nach Verfallsdatum gelöscht. Das Zeitfenster hat also den Rahmen [Totzeit, Verfallsdatum].

Das Verfahren löst auch das Doppelklick-Problem: Es erfolgt nur ein Eintrag, auch bei einem Doppelklick auf den Submit-Button.

Probiers mal aus ;)

Horst Sonnenschein

[mod]

»Unbenutzte IDs werden nach Verfallsdatum gelöscht. Das Zeitfenster hat also den Rahmen [Totzeit, Verfallsdatum].

Welche Größe sollte die Gültigkeitsdauer einer ID besitzen?

gruß, mod.

[hotti]

»Unbenutzte IDs werden nach Verfallsdatum gelöscht. Das Zeitfenster hat also den Rahmen [Totzeit, Verfallsdatum].

Welche Größe sollte die Gültigkeitsdauer einer ID besitzen?

Ja, das Zeitfenster ;)

Totzeit => im Sekundenbereich

In etwa die Zeit, die ein Besucher braucht, zu raffen, für was das Eingabeformular gemacht wurde. Entspricht einem normalen, nicht-Bot-Verhalten: Formular erst laden, ausfüllen, Submit.

Doofe Bots submitten gleich.

Verfallsdatum => im Stundenbereich

Die Zeit, die einem Besucher zugemutet werden kann, das Formular auszufüllen. Kaffeepause/Bier inbegriffen.

Hotti