nikosch

Heyho, hab mal wieder ne kleine Verständnisfrage.

Ich sitze gerade an ner neuen Authentifizierungs-Klasse, ein typisches Login Formular mit DB und Session. Ich hadere noch an einem Punkt. Gegen Spam und Bruteforcing möchte ich die Anzahl der Loginversuche auswerten und je nach Anzahl geeignete Maßnahmen starten (Sleep - Account zeitweise inaktiv - Account Sperrung). Angedacht hatte ich dabei die ohnehin schon existente Session zu nutzen (keine Angst, nach erfolgreichem Account gibts ne neue Session) um die Versuche zu zählern, aber ist das sinnvoll? Oder muß ich bei jedem Loginversuch einen Datenbankeintrag machen?
Wäre für ein paar Tipps (auch sonstige in diesem Themenbereich) dankbar.

Gruß --ick

Mister Ad

Flor1an

Wenn das Programm welches die Bruteforce angriffe startet keine Session zulässt, dann bringt dir es auch garnichts die Versuche in einer Session zu speichern. Also wenn du sicher gehn willst würd ichs in die DB eintragen.

pepe24

Denke nicht, dass das ein logischer schluss ist. Wenn keine Session zugelassen wird, dann sollte man das bruteforce programm / den user gleich auf eine Fehlerseite leiten. Was bringt einem ein Loginsystem, wenn keine Sessions zugelassen werden?
Eine Datenbank würde ich dafür nicht hernehmen...

Das mit der Account-Sperrung finde ich auch nicht so toll. (kommt auf das system an)
Denn der Übeltäter braucht nur besagte Benutzernamen, die selten geheim sind, um beliebigen Usern immer wieder den zugang durch eine Attacke und der nachfolgenden Sperre des Benutzers zu verwehren.


EDIT: Hier ging es schonmal um das Thema. Vielleicht hilfts ja. http://www.phpfriend.de/forum/ftopic61137.html

nikosch

Danke für den Link, ich erinnere mich noch an den Thread. Ich überlege aber vielmehr, ob es effektiv möglich ist, Fehlanmeldungen ohne ständigen Zugriff auf die DB behandeln zu können. Unabhängig der Diskussion dort, werde ich wahrscheinlich wirklich Sleep und die Sperrung für 15-30 Minuten implementieren. Ne andere sinnvolle Möglichkeit sehe ich nicht. Gegen IP Sperrung hab ich was.

Slava

Ok!
wir schreiben alle Versuche in DB. Und weiter?
Wie werden wir aber diese Versuche zu dem user zuordnen?
ip-adresse von dem User als identifizierung betrachten?
da können wir aber bei proxis direkt mehrere besucher nicht mehr von einander unterscheiden.
betrachten dann eine gebeude mit mehreren pc als einen User?

Welche möglichkeiten haben wir eigentlich um einen user zu identifizieren?
das sind eigentlich zufalswerte die wir von eine seite zur anderer übergeben, und können dann an diesem wert einen user identifizieren.
Eigentlich macht Session gerade das, was ich eben beschrieben habe und nimmt mir einfach die arbeit ab das selbe von hand zu programmieren.

Also ich kann eigentlcih nur session in betracht ziehen um so was zu realisieren.
Wenn der user seine 3 falsche eingaben gemacht hat, muss man versuchen die zeit zwischen den versuchen zu zählen und wenn es mehrere falsche versuche innerhalb von sehr kurzer zeit vorkommen, erst dann hat es ein sinn die ip zu sperren, da wir ein realistische verdacht auf ein automatischer angriff haben.

__________________
Slava
http://bituniverse.com

KingCrunch

Dann schaltet man Cookies aus und die Session spielt nicht mehr mit

__________________
Nicht jeder Fehler ist ein Bug.

Slava

wer sagt, dass session nur über Cookies läuft?
bei einer normaler webanwendung weisst du schon nach dem 2-tem seitenaufruf ob der Keks gesetzt wurde.
wenn nicht, dann übergibst du einfach session_id über GET bzw POST weiter. wenn du kein zugriff auf php.ini hast, dann machst du einfach mit
output_add_rewrite_var(session_name(),session_id() );
weiter, ohne dir weitere gedanken zu machen.

gibt es bessere vorschläge um einen user zu identifizieren?

__________________
Slava
http://bituniverse.com

KingCrunch

Das setzt voraus, dass der Bot da mitmacht Es ist nun keine Schwierigkeit, dass du ein bruteForce-Programm schreibst, welches die SID sei es über GET, POST oder COOKIE entfernt und der dann jedes mal eine neue Session bekomt

__________________
Nicht jeder Fehler ist ein Bug.

Slava

ich glaube, dass wir in Moment über verschiedende Sachen sprechen
eine bruteForce-Programm wird versuchen sich einzuloggen, bzw nach dem Zufallsprinzip schon vorhandene session_id zu bekommen. in diesem Fall können wir von mir vorgeschlagene Zeitmessung zwischen Versuchen zu machen oder Anzahl von sessions zu begrenzen.
Aber die frage bleibt weiter offen wie willst du denn anderes einen user identifizieren?
wie willst du der Anzahl von falschen Versuchen ohne rücksicht, ob es in db, datei oder shared memory gespeichert wird, zu einem user zuordnen?

OT:
<<Es ist nun keine Schwierigkeit, dass du ein bruteForce-Programm schreibst>>
hast du schon eine geschrieben?

__________________
Slava
http://bituniverse.com

KingCrunch

Nö, aber was steckt da schon groß drin? Eine Wort-Liste und ne Schleife, im Groben wars das

__________________
Nicht jeder Fehler ist ein Bug.