Bruteforce verhindern (IP-Check)

[cortex]

Zitat von reinhardlange

beim Login-Formular ein "unsichbares Feld" mittels css einbauen und prüfen, ob etwas eingetragen wurde

das mag für spam-bots gut funktionieren, da diese - soweit ich weiss - das netz "automatisch" durchkämmen und ihren müll dort abladen, wo sie eine (bekannte) lücke finden. der markt für foren- und blog-apps wird ja auch durch einige wenige dominiert.
beim angriff auf eine konkrete anwendung hingegen wird diese (händisch) auf angriffsvektoren abgeklopft. das programm wird mit den gewonnenen informationen gefüttert und erst dann für den automatischen angriff gestartet.

bitte korrigiert mich, wenn ich daneben liege.

cx

[DokuLeseHemmung]

was dieses prinzip mit den dynamischen namen der input-felder zu tun haben soll...

Wenn die Anordnung der Textfelder im Formular erhalten bleibt, ist es für einen Bot ein leichtes sie zuzuordnen, egal welche Namen sie tragen. Der Bot muß nur einmal instruiert werden. Auch kann er problemlos ein type='password' von einem type='text' unterscheiden. Das würfeln der Feldbenennungen bringt also nur herzlich wenig. Zumindest in Sachen Bruteforce Attacken. Und deinem GoogleBrowser scheint das ja auch sowieso egal zu sein.

das kann auch teil des sicherheistkonzeptes einer app sein. die autovervollständigung stellt immerhin ein gewisses sicherheitsrisiko dar - denk mal an öffentlich zugängliche arbeitsstationen oder nicht-privatrechner, die der user nicht selbst verwaltet.

Natürlich!
Aber da gibts ja noch das HTML5 Attribut: autocomplete="off" Leider ist es noch kein Standard, wird aber von allen Browsern verstanden.

[cortex]

Zitat von DokuLeseHemmung

Wenn die Anordnung der Textfelder im Formular erhalten bleibt, ist es für einen Bot ein leichtes sie zuzuordnen, egal welche Namen sie tragen.

genau das habe ich mir gedacht / befürchtet.

Zitat von DokuLeseHemmung

Und deinem GoogleBrowser scheint das ja auch sowieso egal zu sein.

1. das ist nicht meiner - ich teste wie jeder verantwortungsvolle entwickler mehrere clients
2. iron ist ein derivat des google-browsers "chrome"

Zitat von DokuLeseHemmung

Aber da gibts ja noch das HTML5 Attribut: autocomplete="off" Leider ist es noch kein Standard, wird aber von allen Browsern verstanden.

prima. es gibt auch das attribut "readonly" für input-elemente. dennoch würde sich kein vernünftiger entwickler darauf verlassen.

cx

[DokuLeseHemmung]

Also, bevor wir und hier irgendwie "streiten", sollten wir das Problem erstmal in seine Teile zerlegen.

1. Bruteforce Attacken (Thema des Threads)
2. DAUs und ihre Formfelder (von uns eingeführt)

Ich würde lieber nur 1 hier abhandeln.
Dass HTML Attribute, egal ob Feld-Namen, Readonly oder AutoComplete gegen Bots nichts ausrichten, sollte uns doch klar sein.
Ausnahme: Google reagiert auf rel="nofollow"
Hier mal was witziges: http://googlewebmastercentral-de.blo...ormularen.html

[cortex]

Zitat von DokuLeseHemmung

Ich würde lieber nur 1 [Bruteforce Attacken] hier abhandeln.

dito. das thema scheint allerdings erschöpft - ich wüsste (vorerst) jedenfalls nichts mehr hinzuzufügen.

off-topic:

Zitat von DokuLeseHemmung

Hier mal was witziges

erkenne den witz an der sache leider nicht. das einzige, was mich amüsiert:

außerdem crawlen wir ausschließlich Formulare, welche die GET-Methode verwenden

google macht das schon...

cx

[DokuLeseHemmung]

Ausserdem untersucht Google auch JavaScript und Flash nach URLs.
Das finde ich mindestens ebenso doll.

[cortex]

@ doku: würde das thema gern nochmal aufgreifen, falls du meine konsequente kleinschreibung nicht ebenso konsequent zu ignorieren gedenkst .-

Zitat von DokuLeseHemmung

fehlerhafte Logins werden geloggt (ohne Passwort)

wieso eigentlich nicht? BF-attacken können sich auch gegen passworte richten. nicht nur das, sie sind auch effektiver, da jede user-id eindeutig ist, ein passwort hingegen nicht (insofern die passworte nicht mit einem individuellen salt gespeichert werden).
die wahrscheinlichkeit, durch wahlloses ausprobieren einen user zu einem vorgegebenen passwort zu finden, ist mithin grösser als umgekehrt.

cx

[DokuLeseHemmung]

konsequente kleinschreibung

Daraus spricht eine gewisse, nunja, nenne ich es mal Verachtung.
Aber das soll hier nicht zu Thema werden.


Deine Begründung, warum man die falschen Passwörter speichern sollte verstehe ich nicht.

Es macht doch keinen Sinn falsche Passwörter zu speichern!
Was willst du damit anstellen? Selber BF Attacken starten?
Das kann es doch nicht sein.


Mein Tipp:
Niemals irgendwo, völlig egal wo, Passwörter im Klartext speichern.

[mgutt]

Zitat von cortex

das mag für spam-bots gut funktionieren, da diese - soweit ich weiss - das netz "automatisch" durchkämmen und ihren müll dort abladen, wo sie eine (bekannte) lücke finden. der markt für foren- und blog-apps wird ja auch durch einige wenige dominiert.
beim angriff auf eine konkrete anwendung hingegen wird diese (händisch) auf angriffsvektoren abgeklopft. das programm wird mit den gewonnenen informationen gefüttert und erst dann für den automatischen angriff gestartet.

bitte korrigiert mich, wenn ich daneben liege.

cx

Bots sind nicht so dumm. Die lesen grundsätzlich erstmal das Formular aus und füttern ihren POST-Datensatz entsprechend.

Login-Schutz:
In phpBB beispielsweise werden die Fehlversuche in der Spalte der User-Tabelle des betreffenden Users zwischengespeichert. Ab X Fehlversuchen ist der Login dann für Y Minuten nicht mehr möglich. Das ist absolut vertretbar, auch aus Usability-Sicht. Auf die Art muss man auch keine IPs speichern. Wenn der Login erfolgreich war, werden die Fehlversuche wieder genullt.

Das klingt erstmal sicher, aber ich kann aus Erfahrung sagen, dass dieses Verfahren nicht ausreichend ist. Ich kenne die drei beliebtesten Passwörter, die im Netz eingesetzt werden und genau die könnte man dann bei jedem User jeweils einmal probieren, bevor der Account weitere Fehlversuche ablehnt. Ich habe das bereits mit eigenen Userdaten getestet. Prozentual gesehen, sind zwar nur wenige Accounts betroffen, aber möglich wäre es.

Dagegen hilft eigentlich nur eine Sperre von zu einfachen Passwörtern. Also man verlangt, dass mindestens eine Kombination aus Groß-, Kleinschrift, Zahlen und Sonderzeichen gegeben ist und die Länge mindestens 6 Stellen umfasst (zu heftige Vorgaben demotivieren, also Vorsicht).

Die Gegenseite wäre dann wirklich nur eine umfangreiche Prüfung von IP-Adressen, Cookie, Session oder was man auch immer als Filter einsetzen möchte.

Ich bin übrigens der Ansicht, dass Bruteforce auf User-Accounts selten ist. Viel mehr wird versucht FTP-, .htaccess-oder MySQL-Logins zu bruteforcen. Da lohnt es sich und vor allen Dingen kann man sich da ganz schlecht vor schützen. Aber ganz klar... einen gewissen Schutz sollte man in jedem Fall integrieren.

[cortex]

Zitat von DokuLeseHemmung

Daraus spricht eine gewisse, nunja, nenne ich es mal Verachtung.

nee doku, keine verachtung. nenn mich arrogant - das ist ok .-

Zitat von DokuLeseHemmung

Deine Begründung, warum man die falschen Passwörter speichern sollte verstehe ich nicht.

szenario: jemand wählt für seinen angriff ein beliebtes pwd aus dem deutschsprachigen raum, z.b. schatzi123. nun werden beliebige user-names x-mal abgeklopft.

1. meine app hat neben der belastung durch automatisierte requests ein viel grösseres problem: auf schatzi123 findet sich irgendwann garantiert ein benutzer-konto. und wie bereits gesagt, durch

user-names : passwort = 1 : n

finde ich zu einem passwort leichter einen user als umgekehrt.

2. logge ich nur falsche passworte, kann der angreifer darauf schliessen, ob ein pwd vergeben ist oder nicht - ich verrate etwas über die daten meiner anwendung.

3. mit den user-names verhält es sich genauso. ich persönlich mache keinen grossen unterschiede zwischen user-names und passworten. ich frage mich auch, warum i.a. das gehashte speichern von passworten, aber nicht von user-names empfohlen wird. wahrscheinlich nur, um mir bei der anmeldung ein hallo user x entgegenzuwerfen.

Zitat von DokuLeseHemmung

Niemals irgendwo, völlig egal wo, Passwörter im Klartext speichern.

wir wollten uns auf gehobenem (fachlichen) niveau unterhalten, nicht wahr?

cx