it-swarm-eu.dev

Warum implementieren Websites das Sperren nach drei fehlgeschlagenen Kennwortversuchen?

Ich kenne die Gründe dafür, unendliche Passwortversuche nicht zuzulassen - Brute-Force-Versuche sind keine Meatspace Schwäche, sondern ein Problem mit der Computersicherheit - aber woher haben sie die Nummer drei?

Ist Denial-of-Service nicht ein Problem bei der Implementierung einer Sperrrichtlinie, die leicht aktiviert werden kann?

Gibt es harte Untersuchungen, die zeigen, welche Anzahl oder welcher Bereich optimal ist, bevor ein Konto gesperrt wird, das die tatsächliche Sicherheitsbedrohung mit der Benutzerfreundlichkeit in Einklang bringt?

Wenn ich es mir überlege, sehe ich keinen messbaren Sicherheitsunterschied zwischen drei Versuchen und 20 Versuchen mit der heute allgemein verwendeten Komplexität des Passworts.

(Ich kenne diese Röcke Subjektivität, aber ich suche nach messungsbasierten Meinungen)

107
Bradley Kreider

Vor kurzem hat Bill Cheswick von AT & T auf der OWASP AppSec 2010-Konferenz in Orange County ausführlich über dieses Problem gesprochen.

Kurz gesagt, es gibt unzureichende Forschung.

In Kürze sind hier einige seiner Ideen für eine weniger schmerzhafte Kontosperrung:

  • Zählen Sie keine doppelten Passwortversuche (sie dachten wahrscheinlich, sie hätten es falsch geschrieben)
  • Geben Sie den Kennworthinweis zum primären Kennwort an und haben Sie kein (schwaches) sekundäres Kennwort
  • Erlauben Sie einer vertrauenswürdigen Partei, für den Benutzer zu bürgen, damit er sein Passwort ändern kann.
  • Sperren Sie das Konto in zunehmenden Zeitschritten
  • Erinnern Sie den Benutzer an Kennwortregeln.
75
Zian Choy

Jede Website, die PCI Data Security Standards entspricht, muss sich an Abschnitte halten

  • 8.5.13 (Begrenzen Sie wiederholte Zugriffsversuche, indem Sie die Benutzer-ID nach nicht mehr als sechs Versuchen sperren.)
  • 8.5.14 (Stellen Sie die Sperrdauer auf 30 Minuten ein oder bis der Administrator die Benutzer-ID aktiviert).

Dies ist leider der Grund, warum viele Websites, die Kreditkarten akzeptieren, drakonische Sperrrichtlinien haben, obwohl ihre Designer möglicherweise nicht unbedingt mit dem übereinstimmen, was sie implementiert haben.

Bearbeiten: Beachten Sie, dass diese Anforderungen nur für Systeme für "Nicht-Verbraucher-Benutzer" gelten, sodass sie keine Auswirkungen auf Kundenseiten haben sollten, die Karten akzeptieren.

37
realworldcoder

Ich habe die Erfahrung gemacht, dass Lock-out-Mechanismen immer beliebter werden (zumindest für Web-Apps). Anstatt Konten nach einer Reihe fehlgeschlagener Versuche zu sperren, fordern Sie zusätzliche Informationen für eine erfolgreiche Authentifizierung an.

22
Tate Hansen

Wäre nicht überrascht, wenn es eher von der Baseball-Regel "Drei Schläge" als von irgendetwas Technischem kommen würde.

Eine Rechtfertigung (für alphanumerische Passwörter sowieso) ist

In der Regel ist ein fehlgeschlagener Versuch entweder ein falscher Typ oder ein CAPS-Ein/Aus-Problem. Sie versuchen also, sich anzumelden und abgelehnt zu werden (1), versuchen es erneut, weil Sie glauben, falsch eingegeben zu haben (2), und stellen dann fest, dass die CAPS-Taste aktiviert ist, sodass Sie beim dritten Versuch einsteigen.

Gilt nicht wirklich zum Entsperren von Mobiltelefonen aus einem Netzwerk, wenn normalerweise ein numerischer Code eingegeben wird.

Bessere Vorschläge sind eine immer größere Verzögerung zwischen aufeinanderfolgenden fehlgeschlagenen Anmeldeversuchen. Zuerst erlauben Sie einen sofortigen Wiederholungsversuch, dann 1 Sekunde, 2, 4, 8 ... Sie warten schnell eine Minute zwischen den Versuchen, was ausreicht, um einen Brute-Force-Angriff zu verhindern.

18
Gary

Ich stimme dem OP zu. Wenn Sie darüber nachdenken, wovor Sie die Sperre schützt, gibt es keinen Unterschied zwischen 3 oder 20 Versuchen (oder 100). Alles, was Sie mit diesen Aussperrungen erreichen, abgesehen von der Bestrafung vergesslicher Benutzer, ist die Verhinderung eines Brute-Force-Angriffs. Sie können es auch verwenden, um eine Warnung auszulösen, dass ein Angriff ausgeführt wird. Dies ist jedoch nicht der Hauptzweck (wenn dies der Fall ist, bedeutet dies, dass Sie Ihre Benutzer absichtlich tun, nur um Ihren eigenen Überwachungsjob zu vereinfachen sehr gute Praxis).

Wenn jemand über Ihre Passwortdatenbank verfügt und diese offline abhacken kann, hat er unbegrenzte Versuche. Ihr Limit von 20 Vermutungen ist dort nicht gut.

Wenn jemand versucht, eine Online-Brute-Force durchzuführen, benötigen Sie lediglich ein Kennwort, das "lange genug" standhält: lang genug, damit Ihr IRT reagiert, oder lang genug, damit Ihr Angreifer aufgibt.

Die Conficker-Passwortdatenbank liegt etwas unter 200 Passwörtern (IIRC) und ist mit einigen der dümmsten Passwörter der Welt gefüllt. Nehmen wir nun an, dass Ihr Passwort nicht in dieser Liste enthalten ist. Wenn Sie 20 Passwortversuche zulassen, beispielsweise pro 15 Minuten, ohne zu sperren, benötigt ein Angreifer mehr als zwei Stunden, um diese Liste zu durchlaufen.

Selbst wenn Sie Ihre Vermutungsliste auf Passwörter eingrenzen, die aus relevanten Informationen über diesen Benutzer erstellt wurden, wie z. B. Kidsname02, Birthday99 usw., erhalten Sie immer noch mindestens ein paar Dutzend Passwörter, wodurch ein Wörterbuchangriff auf etwa eine Stunde oder länger verlängert wird Mehr. Diese ständige, fehlerhafte Vermutung im Laufe der Zeit sollte Ihre Alarme auslösen, nicht eine Handvoll falscher Passwörter in ein paar Minuten.

Wenn Sie also Ihre Benutzer von den grundlegendsten Fallstricken bei Kennwörtern fernhalten können, können Sie viele fehlerhafte Kennwortversuche gerne akzeptieren.

Persönlich ziehe ich die Grenze bei 15. Völlig willkürlich und meistens praktisch: Ich finde, dass jeder echte Benutzer lange vorher aufgegeben hat. Wenn es so viele Versuche gibt, ist es normalerweise ein Prozess oder eine Sitzung, die irgendwo mit alten Anmeldeinformationen hängt. Und wenn dies nicht der Fall ist, können wir über die Suche nach Angriffen sprechen.

15
itinsecurity

Es ist eine dumme willkürliche Regel, die das Risiko einer seltsamen Art von DDOS-Angriff birgt. Nehmen wir an, Marv hasst Website X und Website X hat eine Y-Anzahl von Versperrungsrichtlinien. Marv könnte eine ernsthafte Hölle aufwerfen, indem ein Skript automatisch zufällige Namen Y-mal mit falschen Passwörtern versucht. Selbst wenn ein Passwort funktionieren würde, würde es Marv wahrscheinlich egal sein und es ignorieren. Dies würde effektiv viele Benutzer für die Website X sperren und viele Benutzerfrustrationen verursachen, und Gott helfe ihnen, wenn sie eine Bank sind, die Sie anrufen müssen, um Ihr Passwort zurückzusetzen. Ich bin überrascht, dass niemand dies versucht hat.

11
AmaDaden

Ich glaube, ich komme zu spät zu dieser Debatte, aber ich hoffe, ich kann hier etwas Nützliches hinzufügen.

Die Kontosperrungsrichtlinie (mit der Anzahl aufeinanderfolgender ungültiger Versuche, die normalerweise für die meisten Organisationen im einstelligen Bereich liegen) wurde nicht ausschließlich gegen automatisierte Brute-Force-Angriffe entwickelt.

Es ist eher ein Schutz gegen das Erraten von Passwörtern durch menschliche Angreifer, insbesondere durch Personen, die bereits einen Teil des Passworts kennen. Angreifer könnten Passwortfragmente von erhalten

  • schulter-Surfen
  • durch Erraten der Muster, die eine Person zur Auswahl ihrer Passwörter verwendet. Immerhin, wie oft hat man Passwörter mit Elementen in einer Sequenz verwendet, wie Passwort # 01 , Passwort # 02 etc.

Der Nachteil ist natürlich, dass bei einem niedrigen Schwellenwert zwangsläufig ein Denial-of-Service und damit verbundene Kosten für das Geschäft auftreten. Das von Microsoft herausgegebene Whitepaper Best Practices für die Kontosperrung enthält einen empfohlenen Wert von 10. Außerdem wird erläutert, wie die Wahrscheinlichkeit eines erfolgreichen Angriffs mithilfe der Parameter in der Kontosperrungsrichtlinie von Windows geschätzt wird:

Angenommen, der Administrator setzt das Kennwort zurück, wenn das Konto mit dem Registrierungswert LockoutDuration von 0 gesperrt ist. Wenn der Registrierungswert LockoutDuration auf 0 und der Registrierungswert LockoutThreshold auf 20 festgelegt sind, kann der böswillige Benutzer 20 Vermutungen verwenden Passwort. Wenn die Sperrdauer 30 Minuten beträgt, hat der böswillige Benutzer alle 30 Minuten 20 Vermutungen gegen dieses Kennwort, bis es geändert wird. Dies ist ein sehr bedeutender Unterschied in der Gesamtzahl der Vermutungen, die dem böswilligen Benutzer zur Verfügung stehen.

Wenn der Administrator das maximale Kennwortalter auf 42 Tage festlegt, hat der erste böswillige Benutzer nur 20 Vermutungen für ein bestimmtes Kennwort, während der zweite böswillige Benutzer 40.320 Vermutungen hat (20 Versuche für immer eine Sperrung, multipliziert mit 48 Sperrungen pro Tag). multipliziert mit 42 Tagen, bevor der Benutzer das Passwort ändert). Mit den Standardkennworteinstellungen gibt es ungefähr 10 ^ 12 mögliche Kennwörter. Dies bedeutet, dass der böswillige Benutzer eine Wahrscheinlichkeit von ca. 0,000004 Prozent (%) hat, das Kennwort zu erraten. Bei einem optimierten Schätzschema wäre dieser Prozentsatz höchstwahrscheinlich ein größerer Prozentsatz.

Natürlich ist es für Laien nicht einfach, eine geeignete Anzahl zu wählen, und solche Entscheidungen sollten sorgfältig abgewogen werden. Daher kann davon ausgegangen werden, dass einige Organisationen sich nicht bemüht haben, die monetären Auswirkungen ihrer Kontosperrungsrichtlinie und den damit verbundenen Vorteil einer Lockerung ihrer Richtlinie unter Beibehaltung des darin enthaltenen Sicherheitsvorteils zu berechnen.

10
Vineet Reynolds

Dies hat zwei Aspekte; Das erste ist, wie Sie bereits erwähnt haben, die Verhinderung von Brute-Force-Angriffen.

Zu diesem Zweck sollte wirklich eine beliebige Anzahl von Versuchen durchgeführt werden - 3, 5, 20, 2000 ... mit einer geeigneten Kennwortrichtlinie (Länge + Komplexität + ...), die einen ausreichend großen Schlüsselraum bietet, beliebig Durch die Art der Drosselung (X Anzahl der Versuche pro Stunde) wird sichergestellt, dass das brutale Erzwingen des gesamten Raums einige Jahrzehnte dauern würde. (Rechne nach).

Selbst wenn - und dies sollte eine Voraussetzung sein - die Sperrung nur vorübergehend ist und nach kurzer Zeit automatisch entsperrt wird.

Somit ist die Anzahl der Versuche vor dem Sperren beliebig.

Hier spielt jedoch ein anderes, subtileres, nicht mathematisches Problem eine Rolle:

Es ist einfach nicht sinnvoll, wenn ein einzelner Benutzer 2000 Mal hintereinander wiederholt ein falsches Passwort eingibt.

Das heißt, wenn Sie willkürlich 2000 wählen, wissen Sie lange vorher, dass dies KEIN legitimer Benutzer ist. Es kommt also wirklich darauf an, was geschäftlich sinnvoll ist, und auf einen geschäftsorientierten Kompromiss zwischen Risikoanalyse.

Ich denke, historisch gesehen war der Kompromiss eher auf die Risikoseite ausgerichtet - da Passwörter kürzer und weniger komplex waren, war der Unterschied von 3 oder 10 größer. Außerdem hatten die Leute weniger Passwörter, so dass sie leichter zu merken waren ... Und die Benutzer waren im Allgemeinen technisch versierter.

Heutzutage sind drei angesichts der geschäftlichen Auswirkungen wirklich nicht sinnvoll. Es ist wirklich eine Frage, was für your App Sinn macht, welche Arten von Benutzern, wie oft sie sich anmelden usw. Ich empfehle normalerweise herauszufinden, wie viele fehlgeschlagene, legitime Versuche wahrscheinlich sind, und dann zu verdoppeln es.

( Wie @realworldcoder erwähnt hat , PCI hat willkürlich sechs ausgewählt, und wenn Sie PCI unterliegen, haben Sie hier keine große Entscheidung. Andernfalls wählen Sie eine Nummer, die für Sie sinnvoll ist.)

8
AviD

Denken Sie daran, dass dies nur bei gezielten Benutzerangriffen funktioniert.

Wenn sich der Angreifer nur darum kümmert, Zugang zum System zu erhalten, kann er einen umfassenden ersten Angriff ausführen (alle bekannten/erratenen Benutzernamen durchlaufen, bevor er zum nächsten Kennwort wechselt). Fügen Sie hinzu, dass es, wenn es richtig gemacht wurde, von einem verteilten Netzwerk von Maschinen stammen könnte, es ziemlich leicht zu erkennen ist, dass das Verzögerungssystem auch nicht funktioniert.

Wie von anderen erwähnt, ist die korrekte Überwachung fehlgeschlagener Versuche, Angriffe frühzeitig zu erkennen, von entscheidender Bedeutung.

Ja, 3 Versuche sind ziemlich willkürlich und bergen ein DoS-Risiko. Ich wünschte wirklich, die Leute würden aufhören, öffentlich zugängliche Systeme zu verwenden ... Bitte!

Eine andere Lösung: 2-Faktor-Identifizierung. RSA-Token. Wenn wir nur die Möglichkeit hätten, ein einzelnes RSA-Token mit einer 'ID-Nummer' persönlich zu besitzen. Wir könnten diese 'ID-Nummer' dann bei jedem System registrieren, das dann den aktuellen Wert vom Token zusammen mit dem Passwort benötigt, um sich anzumelden.

Aber das wirft eine ganze Reihe anderer Probleme für die Implementierung und das Vertrauen auf ...

7
Dan McGrath

Öffentliche Unternehmen (Verkauf von Aktien an Börsen) unterliegen dem Sarbanes-Oxley Act und werden mehrmals jährlich auf ihre Einhaltung überprüft. Kritische Softwareanwendungen müssen bestimmte Sicherheitsfunktionen erfüllen, um Konten nach fehlgeschlagenen Kennwortversuchen zu sperren.

Die meisten dieser Anwendungen werden in das Active Directory des Unternehmens integriert, für das die Funktionen bereits aktiviert sind.

3
Jose

Hier ist eine wirklich nette Lektüre, die über das hinausgeht, wonach ich glaube, dass Sie suchen. Sie nahmen Daten von Studenten mit einer Drei-Streik-Politik, einer Zehn-Streik-Politik und einer Endlos-Streik-Politik, um darauf hinzuweisen, dass wir die Zahl von drei auf zehn erhöhen (da dies den Erfolg der Anmeldung ungefähr verdreifacht).

Zurück zu einer subjektiven Sichtweise hier ...

Warum wenden die meisten Orte eine Drei-Streik-Politik an? Es ist sicherlich nur eine Heuristik, die sich im Laufe der Zeit entwickelt hat. Drei Versuche sind mehr oder weniger ein Mittelweg für Administratoren und Benutzer, da drei Chancen mehr als ausreichend sind.

Die Idee hinter einem Passwort ist, dass Sie es kennen sollen. Sie sollten wirklich nicht mehr als einen Versuch benötigen . Ich verstehe, dass Fehler gemacht werden, aber in einem Krieg ... haben Sie wirklich nur eine Chance zu beweisen, dass Sie ein Verbündeter sind, oder?.

3
user124863

Sie müssen 3 zufällig ausgewählt haben. Das ist extrem niedrig. Vielleicht hatten sie in der Vergangenheit Sicherheitsprobleme und haben eine niedrige Sperrnummer gewählt, anstatt das Problem richtig zu adressieren oder zu beheben.

Ich bevorzuge die Methode, den Benutzer in zunehmenden Zeitschritten auszusperren. Ich würde es jedoch nicht vom Benutzernamen abtasten, sondern stattdessen die IP-Adresse der Person verwenden, da die Person möglicherweise mehrere Benutzernamen ausprobiert. Ich habe die Sperrzeit auf (Anzahl ungültiger Anmeldeversuche) ^ 2 Sekunden eingestellt, sobald der Benutzer 5 ungültige Versuche erreicht hat. Wenn der Benutzer sein Kennwort bei einer relativ geringen Anzahl von Versuchen nicht kennt, verwendet er meistens ein Kennwortwiederherstellungstool, wenn die Site eines bereitstellt. Wenn es ein echter Hack-Versuch ist, wird es für den Hacker so frustrierend, dass er schließlich aufgibt. Bots werden es so oft versuchen, dass sie sich fast nie anmelden dürfen. Wenn sie beispielsweise 1000 Passwörter ausprobieren würden (was ohnehin lange dauern würde), müssten sie 11 1/2 Tage warten, bevor sie könnten Versuchen Sie das 1001. Passwort. Sie können die Abschreckungsfähigkeit leicht erhöhen, indem Sie den Multiplikator auf ^ 3 erhöhen. Alles darüber kann für gültige menschliche Benutzer etwas zu hoch werden.

2
Rush Frisby

Vor nicht allzu langer Zeit habe ich ein Anmeldesicherheitsschema implementiert, das die folgenden Grundregeln befolgt:

  1. Der erste fehlgeschlagene Versuch gibt sofortiges Feedback. Sie haben es wahrscheinlich fett gefingert.
  2. Der zweite bis fünfte fehlgeschlagene Versuch führte dazu, dass die Antwort pro fehlgeschlagenem Versuch um eine Sekunde verzögert wurde. zB 2 Sekunden, 3 Sekunden, 4 Sekunden ...
  3. Wenn der fünfte Versuch fehlschlug, wurde die Sitzung beendet und ihnen wurde eine Meldung angezeigt, dass sie ihren Browser schließen und es erneut versuchen müssten.

Für mich war dies mehr als ausreichend, um Brute-Force-Angriffe zu verhindern. Dies wäre für Endbenutzer höchstens eine Unannehmlichkeit und würde keine zusätzliche Arbeit für den Support schaffen.

2
Josh