Anzahl der Brute-Force-Versuche für ein durchschnittliches Passwort / nicht aufdringliche, aber sinnvolle Grenzen?

Question

Es gibt mehrere nützliche Antworten auf SO bezüglich der Verhinderung von Brute-Forcing eines Passworts für einen Webdienst durch Anwendung von Drosselung. Ich konnte jedoch keine guten Zahlen finden und habe wenig Erfahrung in diesem Bereich, also lautet die Frage:

Wie viele Versuche sind in der Regel erforderlich, um ein durchschnittliches Kennwort mit 6 oder mehr Zeichen zu erzwingen (ohne zusätzliches Wissen, das hilfreich sein könnte, aber unter Berücksichtigung der Tatsache, dass Kennwörter wahrscheinlich anfällig für Wörterbuchangriffe sind), und was sind auf dieser Grundlage sinnvolle Grenzen für die Anwendung des Drosselungsalgorithmus, ohne die Benutzererfahrung zu beeinträchtigen?

Dies ist mein derzeitiger Plan:

• Das Anmeldeformular verwendet eine Nonce, so dass der Angreifer einen kompletten Anfragezyklus abwarten muss, um sowohl das Ergebnis des Anmeldeversuchs zu erhalten als auch ein neues Token abrufen zu können.
• Ich erlaube es, dass das Anmeldeformular 50 Mal pro IP abgerufen wird, wobei der Abstand zwischen den Anfragen weniger als eine Minute beträgt; danach wird die IP für 1 Minute gesperrt. Bei jedem neuen Versuch innerhalb dieser einen Minute wird die Zeitüberschreitung neu gestartet.
• Es gibt eine sleep für jeden Abruf der Anmeldeseite von # of attempts / 5 So dauert es nach 5 Anfragen mit weniger als einer Minute Abstand zwischen den Anfragen > 1 Sekunde, um das Formular abzurufen, nach 10 Anfragen > 2 Sekunden, usw.
• Außerdem erlaube ich nur 100 fehlgeschlagene Anmeldeversuche pro Benutzerkonto mit einem Abstand von 2 Stunden zwischen den Versuchen, danach wird das Konto für 2 Stunden gesperrt.
• Um häufige DoS'ing von Konten zu vermeiden, können IPs auf eine Whitelist gesetzt werden (keine Beschränkungen) oder auf eine Blacklist (jeder Anmeldeversuch wird vollständig ignoriert).

Auf der Grundlage der bisherigen Antworten habe ich das System so geändert, dass es wie folgt funktioniert:

• Der Abruf des Anmeldeformulars wird schrittweise pro IP verlangsamt. Jede neue Anfrage wird geschlafen für # of requests / 2 Sekunden. Der Zähler wird nach 10 Minuten ohne Anmeldeaktivität zurückgesetzt.
• Ich führe einen FIFO-Stapel von Anmeldeversuchen für jede IP. Wenn sich eine IP innerhalb von 2 Stunden 30 Mal nicht anmeldet, wird sie gesperrt. Ich führe auch eine Liste der Anzahl der Sperrungen pro IP, und die Sperrzeit wird wie folgt berechnet 2 ^ (# of suspensions + 1) hours . Dies sollte zu einer schnellen De-facto-Blacklisting von ständig verstoßenden IPs führen.
• Außerdem wird ein Konto, das sich innerhalb eines Tages 20 Mal nicht angemeldet hat, für 2 Stunden gesperrt. Ich bin mir bei dieser Maßnahme noch nicht so sicher, da dies bedeutet, dass Konten ganz einfach mit DoS'd angegriffen werden können. Wenn es sich nicht gerade um ein riesiges, verteiltes Botnetz handelt, sollten die IPs der Angreifer jedoch schneller auf die schwarze Liste gesetzt werden, als ein Konto dauerhaft mit DoS belegt werden kann. Es ist auch eine recht effektive Maßnahme zum Schutz eines Kontos.

Meiner Meinung nach sollten diese Beschränkungen normalen Nutzern nicht schaden, selbst wenn sie regelmäßig ihr Passwort vergessen und mehrmals versuchen, sich einzuloggen. Die IP-Beschränkungen sollten auch bei Nutzern mit starkem NAT problemlos funktionieren, wenn man die durchschnittliche Größe des Dienstes bedenkt. Kann jemand mit soliden Berechnungen beweisen, dass dies effizient oder ineffizient ist?)

Answer 1

Sie haben dort einige gute Kontrollen, aber Sie sollten sie wirklich mehr straffen. Ein regelmäßiger Benutzer sollte sich nicht mehr als fünfmal nicht anmelden. Wenn er es doch tut, zeigen Sie ihm ein CAPTCHA.

Denken Sie daran, dass Sie das Konto unter keinen Umständen sperren dürfen. Das nennt man eine Schwachstelle bei der Kontosperrung. Dadurch kann ein beliebiger Benutzer andere Benutzer aus dem Dienst ausloggen (DOS, Denial of Service).

Ich habe mich diesem Problem der Anmeldedrosselung schon oft genähert, und die Methode, die mir gefällt, ist, dass Sie ein Feld für fehlgeschlagene Versuche und das Datum des letzten Fehlversuchs in Ihrer Datenbank anlegen. Immer, wenn sich jemand (irgendjemand) nicht bei Konto X anmelden kann, erhöhen Sie den Wert der Fehlversuche von X und aktualisieren das Datum des letzten Fehlversuchs. Wenn die Anzahl der Fehlversuche Y übersteigt (z. B. fünf), zeigen Sie ein CAPTCHA für den betreffenden Benutzer an. So haben Sie keine riesige Datenbank mit gesperrten IPs, um das Anmeldeformular zu drosseln, sondern nur zwei weitere Felder pro Benutzer. Außerdem macht es wegen der Botnetze und Proxies (sowohl legale als auch illegale) wenig Sinn, die Sperre auf der Grundlage von IPs zu verhängen bzw. zu drosseln. Wenn IPv6 in Mode kommt, werden Sie vermutlich noch mehr aufgeschmissen sein. Es ist viel sinnvoller, Drosselungen auf der Grundlage von Zielkonten vorzunehmen. Wenn also Ihr Konto X von einem Botnetz angegriffen wird, wird das Anmeldeformular mit einem CAPTCHA gedrosselt. Der offensichtliche Nachteil dabei ist, dass, wenn Ihr CAPTCHA fehlschlägt, auch Ihre Anmeldedrosselung fehlschlägt.

Im Wesentlichen geht es also so:

• Jemand konnte sich nicht bei Konto X anmelden - vergrößern Sie das Feld Fehlversuche.
• Wenn es mehr als 5 Fehlversuche gibt und der letzte Fehlversuch eine Stunde zurückliegt, scheint es, dass das Konto angegriffen wird.
• Wenn der letzte fehlgeschlagene Versuch mehr als einen Tag zurückliegt, scheint der Angriff beendet zu sein, senken Sie Ihre Schilde und verlangen Sie kein CAPTCHA.

Es handelt sich im Grunde um einen Schutzschild, der aktiviert wird, wenn ein massiver, gezielter Angriff auf bestimmte Konten erfolgt. Das Gute an dieser Art von Ansatz ist, dass es keine Rolle spielt, ob ich eine Farm von PCs auf der ganzen Welt besitze - ich kann kein einziges Konto mit roher Gewalt angreifen, weil es kontenbasiert ist.

Das Schlimme daran ist, dass Sie nichts mehr haben, wenn das CAPTCHA fehlschlägt. Sie könnten diese Situation natürlich auch durch andere Schutzmechanismen verbessern. Das zweite Problem ist, dass ich, wenn ich ein Bot-Netz hätte, einen PC pro Konto verwenden könnte, und dann ist es wahrscheinlich, dass ich bei einem Netzwerk mit einer Million Computern mindestens ein Konto knacke, aber dieser Ansatz funktioniert nur bei nicht gezielten Angriffen.

Ich hoffe, dies hat Ihnen einige Anregungen gegeben.

Answer 2

Aus der Frage geht hervor, dass sie höchstens 50 Passwörter pro Minute ausprobieren können. Ausgehend davon und unter Verwendung zufälliger 6-stelliger Passwörter:

• alle Kleinbuchstaben: 26^6 = 308.915.776 mögliche Passwörter = Im schlimmsten Fall 12 Jahre im Durchschnitt 6 Jahre
• Kleinbuchstaben und Zahlen: 36^6 = Maximal 82 Jahre 41 Jahre im Durchschnitt

Natürlich wären Wörterbuchangriffe viel schneller, aber dazu fehlen mir die Zahlen.

EDIT: Ich habe versucht, die Ergebnisse des Google-Rechners zu verlinken, die dies bestätigen, aber ^ scheint die Links hier durcheinander zu bringen.

EDIT2:

Wörterbuchangriffe (von http://www.outpost9.com/files/WordLists.html ) :

• alle aufgeführten Wörter (75.000): ~1 Tag
• Liste von 816 gängigen Passwörtern: ~16 Minuten
• wirklich lange Wortliste: ~12 Tage (Ich habe mir das angesehen und vermute, dass es die Passwörter der meisten nichttechnischen Personen enthält)

Der letzte Punkt ist beängstigend, aber 12 Tage sind immer noch eine lange Zeit. Wenn Sie wirklich besorgt sind, könnten Sie jedes falsche Passwort verfolgen, bis der Benutzer ein richtiges Passwort erhält. Wenn die Liste dann mehr als 100 verschiedene Versuche enthält, sperren Sie einfach die IP-Adresse und senden Sie dem Benutzer eine E-Mail.

Answer 3

Ich finde die Antwort von @Tower im Allgemeinen gut, bevorzuge aber eine Variante, die ohne CAPTCHA auskommt, vor allem, weil ich es als Benutzererfahrung hasse.

Fügen Sie zusätzlich zu den Feldern für die Fehlerverfolgung auch ein Feld für die Sperrung mit einem Zeitstempel hinzu. Ich stimme zu, dass das Sperren eines Benutzers für immer (oder bis zum manuellen Zurücksetzen) eine schlechte Erfahrung ist, aber Die Sperrung eines Kontos für eine Stunde (auch wenn sie ein wenig schmerzhaft ist) ist eine wirksame Abschreckung. .

Die Änderung würde dann darin bestehen, dass bei einer Erhöhung der Fehlerzahl über den Schwellenwert hinaus das Sperrfeld auf now + 1 hour . Bei jeder Authentifizierung wird dieses Feld überprüft, und wenn lockout > now dann schlägt es fehl.

Das manuelle Sperren von Konten aus administrativer Sicht ist dann nur noch eine Frage des Setzens des Sperrfelds auf einen weit in der Zukunft liegenden Wert wie 9223372036854775807l (max. 64-bit signed long).