Andreas: Hacker-Angriff auf geschützen HTTP-Bereich erkennen

Beitrag lesen

hi!

Traditionellerweise fügt man einfach ein sleep(3) (evt. auch mit anderen Werten für 3) ein, wenn man feststellt dass das Passwort falsch ist. Wenn deine Passwörter so gewählt sind, dass sie sich mit einem Versuch alle 3 Sekunden in annehmbarer Zeit brute forcen lassen, dann hast du was falsch gemacht.

stimmt, da hatte ich auch schon dran gedacht, das ist wohl das beste.

Immer wieder schön ist es auch, die Anzahl fehlgeschlagener Versuche pro Benutzernamen zu speichern und die Zwangspause Stück-für-Stück zu erhöhen, bzw. den Benutzernamen nach einer festgelegten Zahl an Fehlversuchen (bei T-Online beispielsweise soweit ich weiss 9) für einen Tag ganz und gar zu sperren, unabhängig vom Passwort. (Sinnvollerweise macht man das nicht mit dem Administratoraccount, aber der hat eh ein sicheres Passwort zu haben)

Ja, aber da ist das Problem, wie erkenne ich einen "2. versuch"? Viele User haben über Poxies schonmal die gleiche IP. Und dann? Sperrst Du alle User mit der IP? Cookies allgemein, oder SessionID wird wohl kein brute-force script mit zurück schicken, also auch nutzlos. Das einzige was mit noch einfile, wäre der "auch manipulierbare) User-Agent in Kombination mit IP und noch irgendeinem sicheren merkmal. Aber auch das ist nicht wirklich gut. Das ist mal wieder dasselbe Problem wie, wie im Thread mit dem schützen des Bereiches überhaupt aufgetaucht war, Clients wiederzuerkennen.

Eventuell musst du dann auch zu einem erfolgreichen Login eine kleine Zwangspause einführen damit man nicht erfolgreich/erfolglos allein schon an der Zeitdauer bis zur Antwort unterscheiden kann.

Hm? verestehe ich nicht. Was ist daran so schlimm, wenn man das unterscheiden kann? Ändert doch nichts an der Sicherheit, oder? Sonst würde ich evtl sleep() direkt am Anfang einfügen, da wird das dann immer ausgeführt, nur was brächte das?

Eine Art lockfile anzulegen, um parallele Einlogversuche (zumindest für den gleichen Benutzername) zu verhindern ist sicher auch nicht falsch.

Das ist gut, eingegebenen Benutzernamen loggen. So weit ich weiß funktionieren die meisten Programme so, dass zu einem bestimmten Benutzernamen per brute-force Passwörter probiert werden. Dann häte man ja einträge mit immer demselben Passwort.

Und wie sollte man dann reagieren? Unterschiedlich ob es ein existierender Benutzername ist, oder nicht? Was könnte man überhaupt noch machen? IP sperren geht wohl nicht, und wenn der keine SesionID oder Cookie hat, kann man da schlecht irgendwas sperren, außer den Benutzername, wenn der existiert. Aber die idee mit sleep() ist wirklich gut, könnte man ja wirklich bei zu vielen vergeblichen Versuchen von einer IP oder mit einem Username weiter hochsetzen.

Grüße
-- Andreas

--
Henryk Plötz
Grüße aus Berlin