drsoong

Hi,

würde mich mal interessieren, ob es inzwischen bessere Konzepte zur Brute Force Abwehr auf der Ebene der Webanwendung gibt, oder was derzeit als Best Practice erachtet wird.

1. IP-Adresse blocken nach x vergeblichen Loginversuchen innerhalb Zeit t

Probleme: Hacker wechseln IP-Adresse extrem schnell. Mehre gute User
nutzen 1 IP und sind gleichzeitig ausgeschlossen.

2. Account sperren nach x vergeblichen Loginversuchen innerhalb Zeit t

Problem: Brute Force Attacken wechseln nicht nur mögliche Passwörter, sondern auch ständig den möglichen User.

3. Anwendung sperren nach x vergeblichen Loginversuchen innerhalb t

Na ja, da würde wohl so mancher User dumm gucken, wenn er erst mal 'ne Zeit lang nicht mehr im System arbeiten darf.

4. User muss Bildcode mit Logindaten eingeben.

Problem: Bei entsprechendem Interesse lesen Hacker diesen Code auch aus, d. h. Sie investieren die Zeit, um eine Ausleseroutine zu schreiben.
Nicht sehr nutzerfreundlich und überfordert bisweilen den "einfachen" User.

Soweit mein Stand. Was sagt Ihr.

Mister Ad

Manko10

Was ich mache, ist den Account für n Minuten zu sperren. Somit können Bruteforce-Angriff zwar nicht verhindert, aber in der Effinzienz stark verringert werden, da pro Account nur x Versuche innerhalb der Zeit t möglich sind.
So ist ein Angriff mit maximal 5 Passwörtern innerhalb von 15 Minuten pro Account nur sehr ineffizient.

EDIT:
Ach, und was auch noch hilfreich sein kann ist eine Erkennung an der Zeit zwischen den Versuchen. Man kann es zwar keinem User zumuten, seine Daten nur alle 10 Sekunden eingeben zu dürfen, aber länger als 2 Sekunden braucht ein Mensch schon. Allein wegen der Dauer der Serveranfrage und -antwort.

__________________
Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”

drsoong

Klingt schon mal sehr gut, danke! Mal sehen, was da noch so geboten wird.

nikosch

Ja, so eine Art logarithmische Verzögerung bei der Verabeitung der Eingabe (erste Eingabe 0 oder 1 Sekunde, zwei 2 Sekunden, dritte 5 Sekunden oder dergl.).

Gegen gleichzeitige IP und Userwechsel nützt wohl nischt so richtig (deshalb danke für die Liste, habe diese eine Problematik ehrlich gesagt noch nie bedacht)

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

StarSt0rm

Das ist eine schöne Frage, jedoch ist die Zeit, für das Eingeben der Daten,
kein gültiges Kriterium. Wieso ist sehr offensichtlich. Es gibt zahlreiche
Add-Ons die einem das ganze abnehmen, zum Beispiel SecureLogin für
Fiirefox. Diese Add-ons erlauben dem User sich per Tastendruck, bei mit ist
das die Leertaste, sich auf der Seite einzuloggen. Somit werde ich wohl kaum
zwei Sekunden dafür brauchen, wobai ist nicht einmal abwarte bin die Seiten
100%ig geladen sind. (Bin halt etwas ungeduldig.)

__________________
gmap – Das jQuery Plug-in für Google Maps anpassen
jQuery – Sternchen Bewertungssystem
Google Chart API – wenn’s mal schnell gehen muss

nikosch

(Zumindest) Ich meine auch eine Latenzzeit zwischen Formulardatenprüfung und nachfolgende Reaktion (Fehlermeldung oder Folgeseite). Bei einem fehlerhaften Login eine oder ein paar Sekunden zu warten ist für einen menschlichen User durchaus zumutbar, für einen Bot der die Reaktion auswerten muß, ist es wahrscheinlich eine halbe Ewigkeit.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Manko10

Doch, 2 Sekunden sind ein gutes Maß. Selbst bei Secure-Login (welches sich selbst auch benutze) dauert es etwas bis

* die Seite gesendet wurde
* die Antwort kommt
* ich die Fehlermeldung gelesen habe
* noch mal geklickt/gedrückt habe

Alles in allem zwei Sekunden, wenn man nicht von irgendjemandem gejagt wird oder an der Parkinsonschen Krankheit leidet.

__________________
Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”

StarSt0rm

Klar, dann habe ich dich etwas falsch verstanden. Ich persönlich sperre die
Accounts nach x versuchen in einer Zeit t für 15 Minuten. Beim nächsten
erfolgreichem Login erscheint dem User eine Nachricht wie "Es wurden
mehrere Versuche unternommen sich mit Ihrem Benutzernamen einzuloggen.
Es wäre nicht verkehrt, wenn Sie ihr Passwort ändern."

So kann man die Angriffe nicht vermeiden, die Sicherheit jedoch stark
erhöhen. Vor allem, wenn man bei "Erstellen" eines Passwortes an einiges
richtet. Man sollte die User nicht zu hochkomplezen Passwörtert zwingen,
aber ihnen deutlich sagen dass die nicht sehr sicher sind.

__________________
gmap – Das jQuery Plug-in für Google Maps anpassen
jQuery – Sternchen Bewertungssystem
Google Chart API – wenn’s mal schnell gehen muss

Manko10

Macht WEB.DE meines Wissens nach auch. Nach einem erfolgreichen Login wird angezeigt, wie viele Fehllogins seit der letzten Anmeldung erfolgt sind, wenn deren Anzahl größer als 0 ist.

__________________
Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”

David

[quote=StarSt0rm;3634Ich persönlich sperre die
Accounts nach x versuchen in einer Zeit t für 15 Minuten.[/QUOTE]

Aber damit sperrst Du auch den legitimen Benutzer für 15 Minuten aus. Dann braucht <Böser Mensch> nur x*96 Attacken pro Tag zu starten, um Benutzer Y dauerhaft auszusperren.