Es gibt mehrere nützliche Antworten zu SO bezüglich der Verhinderung der Brute-Erzwingung eines Passwortes eines Web-Services durch Anwendung von Throttling. Ich konnte jedoch keine guten Zahlen finden, und ich habe wenig Erfahrung in diesem Bereich, also ist die Frage:
Wie viele Versuche dauert es normalerweise, um ein durchschnittliches Passwort von 6 oder mehr Zeichen (ohne zusätzliches Wissen, das helfen kann, aber unter Berücksichtigung, dass Passwörter wahrscheinlich anfällig für Wörterbuchangriffe sind) zu erzwingen und darauf basierend, was sind sinnvolle Grenzen für den Drosselungsalgorithmus, ohne die Benutzererfahrung zu stören?
Dies ist mein derzeitiges Schema:
sleep , das für jeden Abruf der Login-Seite von # of attempts / 5 gilt, also nach 5 Anfragen mit weniger als einer Minute zwischen den Anfragen wird & gt; 1 Sekunde, um das Formular nach 10 Anfragen & gt; 2 Sekunden usw. Basierend auf den bisherigen Antworten habe ich es so optimiert, dass es so funktioniert:
# of requests / 2 Sekunden geschlafen. Der Zähler wird nach 10 Minuten ohne Anmeldeaktivität zurückgesetzt. 2 ^ (# of suspensions + 1) hours berechnet. Dies sollte zu einer schnellen De-facto-Blacklisting von ständig beleidigenden IPs führen. Ich denke, dass diese Grenzen normalen Benutzern nicht schaden sollten, selbst wenn sie ihr Passwort regelmäßig vergessen und versuchen, sich mehrmals anzumelden. Die IP-Grenzwerte sollten auch bei stark NAT-Nutzern angesichts der durchschnittlichen Größe des Dienstes in Ordnung sein. Kann jemand beweisen, dass dies effizient oder ineffizient ist? :)
Aus der Frage klingt es wie das schnellste, das sie versuchen könnten, Passwörter ist 50 pro Minute. Basierend darauf und mit zufälligen 6-stelligen Passwörtern:
Natürlich wären Wörterbuchangriffe viel schneller, aber ich habe keine Zahlen dafür.
BEARBEITEN: Ich habe versucht, Google-Rechnerergebnisse zu verknüpfen, die dies unterstützen, aber ^ scheint hier Links zu vermasseln.
EDIT2:
Wörterbuchangriffe (von Ссылка ):
Der letzte ist gruselig, aber 12 Tage ist noch eine lange Zeit. Wenn Sie wirklich besorgt sind, können Sie jedes falsche Passwort verfolgen, bis der Benutzer ein korrektes Passwort erhält, und wenn die Liste zu 100 verschiedenen Versuchen erscheint, verbieten Sie einfach die IP-Adresse und senden eine E-Mail an den Benutzer.
Sie haben ein paar gute Kontrollen dort, aber Sie sollten es wirklich mehr anziehen. Ein regulärer Benutzer sollte sich nicht mehr als fünf Mal anmelden. Wenn er es tut, zeigen Sie ihm ein CAPTCHA.
Denken Sie daran, dass Sie das Konto unter keinen Umständen sperren sollten. Es wird eine Sicherheitslücke für die Kontosperrung genannt. Dies ermöglicht es einem beliebigen Benutzer, andere Benutzer vom Dienst abzumelden (DOS, Denial of Service).
Ich habe dieses Problem der Anmeldedrosselung oft angegangen, und das eine, das ich mag, ist, dass Sie ein Feld fehlgeschlagener Versuche und das Datum des letzten fehlgeschlagenen Versuchs in Ihrer Datenbank erstellen. Immer wenn jemand (irgendjemand) es versäumt, sich bei Konto X anzumelden, erhöhen Sie den Wert der fehlgeschlagenen Versuche von X und aktualisieren das letzte fehlgeschlagene Versuchsdatum. Wenn der Zählwert für fehlgeschlagene Versuche Y überschreitet (z. B. fünf), wird ein CAPTCHA für den bestimmten Benutzer angezeigt. Sie werden also keine riesige Datenbank mit verbotenen IPs haben, um das Login-Formular zu drosseln, stattdessen haben Sie nur zwei weitere Felder pro Benutzer. Es macht auch wenig Sinn, basierend auf IPs, wegen Botnets und Proxies (sowohl legale als auch illegale) zu bannen. Wenn IPv6 in Mode kommt, werden Sie mehr zum Scheitern verurteilt sein, als ich annehme. Es ist viel sinnvoller, basierend auf Zielkonten zu drosseln. Wenn Ihr Konto X von einem Botnet angegriffen wird, wird das Anmeldeformular mit einem CAPTCHA gedrosselt. Der offensichtliche Nachteil hier ist, dass, wenn Ihr CAPTCHA fehlschlägt ... ebenso Ihre Login-Drosselung.
Also, im Wesentlichen geht es so:
Es ist im Grunde ein Schild, der sich einschaltet, wenn es einen massiven gezielten Angriff gegen bestimmte Konten gibt. Das Gute an dieser Art von Ansatz ist, dass es egal ist, ob ich eine Farm von PCs auf der ganzen Welt besitze - ich kann kein einziges Konto rotieren, weil es auf einem Konto basiert.
Die zwei schlimmen Dinge dabei sind, dass, wenn das CAPTCHA fehlschlägt, nichts mehr übrig ist. Sie könnten diese Situation natürlich verbessern, indem Sie auch andere Schutzmaßnahmen ergreifen. 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 mit einer Million Computernetzwerk mindestens ein Konto knacke, aber dieser Ansatz funktioniert nur bei nicht gezielten Angriffen.
Ich hoffe, das hat Ihnen einige Gedanken gegeben.
Ich mag generell die Antwort von @ Tower, bevorzuge aber eine Variante, die CAPTCHA nicht verwendet, hauptsächlich weil ich es als Benutzererfahrung hasse.
Fügen Sie zusätzlich zu seinen Fehlernachverfolgungsfeldern ein Sperrfeld mit einem Zeitstempel hinzu. Ich stimme zu, dass das Aussperren eines Benutzers für immer (oder bis zum manuellen Zurücksetzen) eine schlechte Erfahrung darstellt, aber mckamey 15.11.2012 21:53
Tags und Links algorithm language-agnostic security brute-force