Das Sperren von Konten ist in erster Linie eine schlechte Idee. Es scheint, als würden Sie Ihre Organisation sicherer machen, indem Sie "schlechte Leute" fernhalten, die Passwörter mit brutaler Gewalt "erraten" Angriffe, aber was hast du wirklich gelöst? Selbst mit dieser Richtlinie und einer perfekten Benutzerbasis, die niemals Sicherheitsfehler macht, kann ein Angreifer einen Denial-of-Service-Angriff auf Ihr Unternehmen ausführen, indem er wiederholt das Kennwort "aaa" verwendet, um die Konten kritischer Benutzer zu sperren. Überlegen Sie, was passiert, wenn Ihr Angreifer eine Kopie der Liste der Benutzernamen für Ihre gesamte IT-Abteilung erhält: Plötzlich wird die IT selbst - die Organisation, die sonst andere Benutzer entsperren könnte - selbst vollständig heruntergefahren.

Überlegen Sie immer, was das Bedrohungsmodell ist, bevor Sie eine Richtlinie implementieren. Ein "Bösewicht", der entschlossen ist, Ihre Organisation zu verletzen, findet alternative Angriffsmethoden. Ihre Aussperrungspolitik wird nicht einmal einen nationalstaatlichen Akteur (wie Russland oder China oder die NSA) beunruhigen. Ein entschlossener Hacker wird einfach andere Wege finden (wie Social Engineering). und es wird nur legitimen Benutzern Ihres Dienstes schaden, egal wie niedrig oder hoch Sie den Sperrzähler setzen.

Moral der Geschichte: Sperren Sie keine Konten. Stattdessen Machen Sie das, was Apple mit dem iPhone macht: Jeder Anmeldeversuch verdoppelt die Anmeldeverzögerung, sodass Sie nach etwa einem Dutzend Fehlern zwischen jedem weiteren Versuch eine Stunde warten müssen. Das ist lang genug, um zu verhindern, dass "böse Jungs" Brute-Force-Angriffe ausführen, aber immer noch kurz genug, damit ein legitimer Benutzer diese Stunde damit verbringen kann, sein Passwort herauszufinden und es nach dem Mittagessen richtig einzugeben - oder sich an die IT zu wenden und entschuldigend um Hilfe zu bitten . (In ähnlicher Weise können "Flooding" -Richtlinien häufig auf IP-Adressebene in Ihrer Firewall implementiert werden, nicht nur auf Benutzerkontoebene in Ihrer Software, wenn Sie Bedenken haben, dass ein dedizierter Angreifer versucht, viele verschiedene Konten brutal zu erzwingen .)

Und wenn Sie keine Konten sperren, müssen Sie keinen Zähler haben - oder anzeigen .

[ siehe auch: diese hervorragende Antwort auf eine ähnliche Frage ]

Dies hängt von Ihrem Sperrmechanismus ab. Wenn ungültige Anmeldungen nach einiger Zeit zurückgesetzt werden UND ein gesperrtes Konto nicht entsperrt wird, kann das Anzeigen eines Zählers einem Angreifer helfen, ein Konto nicht zu sperren. Ein erfahrener Angreifer hat jedoch die Sperrrichtlinie im Voraus festgelegt und berücksichtigt dies beim Erraten des Kennworts. Die Auswirkungen sind also begrenzt.

Wenn Sie sich zum Schutz Ihres Anmeldemechanismus darauf verlassen, fehlt der Punkt. Sie sollten eine angemessene Kennwortrichtlinie und eine entsprechende Sperrrichtlinie haben. Wenn die Kennwortrichtlinie stark ist, muss ein Angreifer eine große Anzahl von Vermutungen anstellen, bevor er sie richtig macht. Wenn Sie nach 20 Versuchen ein Konto sperren, besteht nur eine geringe Wahrscheinlichkeit, dass Sie kompromittiert werden.

Sie müssen sich fragen: Was bringt es, diese Informationen einem echten Benutzer anzuzeigen? Dieses Problem mit der Sperrung tritt häufig auf, weil die Anzahl der Versuche zu niedrig eingestellt ist. 3 oder 5 sind übliche Entscheidungen. NIST (derzeit aufgrund der Schließung der Regierung nicht verfügbar, daher noch kein direkter Verweis) schlägt weniger als 100 Versuche vor.

NIST hat einen Punkt: Denken Sie an ein Passwort, das kein Angreifer in 3 erraten wird Versuche, die sie aber in 100 Versuchen erraten werden. Alle Angreifer verwenden unterschiedliche Wörterbücher und Ansätze. Wenn ein Passwort unsicher ist, um 100 Vermutungen standzuhalten, kann es auch mit weniger Versuchen verletzt werden - obwohl dies weniger wahrscheinlich ist. Daher ist eine gute Kennwortrichtlinie ein Muss.

Ich werde die NIST-Referenzen hinzufügen, wenn die Site wieder hochgefahren wird. Troy Hunt hat einige gute Blog-Beiträge, die Passwort- und Anmeldemechanismen zusammenfassen. Er ist auch ein Fan der NIST-Richtlinien.

Grundsätzlich sollte es kein Sicherheitsrisiko sein. Wenn dies der Fall wäre, würden Sie sich auf Sicherheit durch Dunkelheit (versteckte Informationen) verlassen.

Das Ausblenden einer Zählung wäre bestenfalls eine geringfügige Unannehmlichkeit für einen Gegner.

Im Gegensatz dazu kann das Ausblenden einer Zählung eine erhebliche Unannehmlichkeit für legitime Benutzer sein. Es ist nicht ungewöhnlich, dass ich manchmal das falsche Passwort eingebe und es dann noch einige Male erneut eingebe, vorausgesetzt, ich habe einen Tippfehler gemacht. Wenn ich weiß, dass ich mit einem anderen falschen Versuch ausgesperrt werde, werde ich mein Passwort nachschlagen und es kopieren / einfügen oder sorgfältig eingeben. Wenn ich mich jedoch unabsichtlich von meinem Konto sperre, muss ich jetzt eine Menge zusätzlicher Probleme auf mich nehmen, um es freizuschalten.

Um eine andere Perspektive zu geben: Für einen erfahrenen Angreifer spielt es keine Rolle .

Wie werden Online-Konten heute normalerweise ^{1 sup>? Es gibt zwei Varianten einer Technik, die häufig verwendet werden.}

Datenbanken mit Kennwort-Hashes (oder Kennwörtern im Klartext) werden gestohlen und von Angreifern offline geknackt. Nach dem erfolgreichen Knacken eines Hashs wird beim ersten Versuch das richtige Kennwort an den Anmeldemechanismus gesendet, sodass dieses Steuerelement unwirksam ist.

Dies kann entweder die Datenbank des betreffenden Dienstes oder em sein > die Datenbank eines anderen Dienstes. Leider neigen die Benutzer dazu, ihre Passwörter mit mehreren Diensten wiederzuverwenden, sodass die Wahrscheinlichkeit hoch ist, dass ein Passwort, sobald es mit einer E-Mail-Adresse übereinstimmt, auf einer anderen Site verwendet werden kann. Ein Angreifer hat möglicherweise zwei oder drei Kennwörter zur Auswahl, aber wahrscheinlich nicht 20. Auch dieses Steuerelement ist unwirksam.

Welche Sicherheitsstufe legt dieses Steuerelement fest? Die Stufe, die erforderlich ist, um sich vor unerfahrenen Script-Kiddies, böswilligen Ex-Partnern und neugierigen Eltern zu schützen, die sich Ihr persönliches Konto ansehen und fünf Passwörter nach dem Zufallsprinzip ausprobieren möchten. Nicht mehr, aber nicht weniger.

^{1 Dann gibt es natürlich auch andere Techniken, die "fortgeschrittener" sind, wie Keylogging, (Speer-) Phishing, MitM usw., die dies ebenfalls sind durch dieses Steuerelement nicht gemildert. sup>}

Damit sind nur zwei Szenarien möglich, aber das Risiko einer Kontosperrzeit wird eher über die Sperrzeit angezeigt.

ZB

• kann die Hydra einmal konfigurieren oder ein anderes Tool, um die Anmeldung brutal zu erzwingen und nach 3 Versuchen zu warten. Wenn Sie nicht genügend Sperrzeit haben, kann dies zu einer Kontokompromittierung führen.

• Wenn Sie ungefähr 30 Minuten Sperrzeit haben, können wir das Tool für Brute Force konfigurieren und warten Sie nach drei Versuchen, bis das Kennwort geknackt ist.

Um daraus zu schließen, besteht kein Risiko darin, einen Kontosperrversuch anzuzeigen.

Je weniger Informationen Sie einem Angreifer geben, desto besser. Wie bereits erwähnt, kann ein Tool so konfiguriert werden, dass es die entsprechende Zeit wartet. Es ist nicht unbedingt ideal, ihnen die Informationen für diese Konfiguration zu geben.

Sie müssen dies jedoch mit den Bedürfnissen Ihrer Benutzer in Einklang bringen. Finden Sie, dass die Systemadministratoren übermäßig viel Zeit damit verbringen, Konten zu entsperren, weil Ihre Benutzer sie weiterhin sperren? Wenn dies der Fall ist, zeigt Ihre Analyse möglicherweise, dass Sie mehr Nutzen daraus ziehen, wenn Sie Ihren Benutzern die Anzahl der Wiederholungsversuche anzeigen, damit diese wissen, wann sie warten müssen, bevor sie ihre Konten sperren. In anderen Fällen ist das Gegenteil der Fall, aber in beiden Fällen sollte die Antwort das Ergebnis einer objektiven Analyse der Kompromisse für das jeweilige System sein.

Ich hoffe, dies hilft.

Das Sicherheitsrisiko ist subjektiv. Es hängt davon ab, was Sie versuchen, um das Ziel der Sicherheitskontrolle und alle anderen vorhandenen Sicherheitskontrollen zu schützen, die das Risiko mindern oder kompensieren.

Basierend auf diesen verschiedenen Unternehmen / Unternehmen werden unterschiedliche Akzeptanz für das gleiche Risiko haben.

Wenn generisch angegeben wird, wie viele Versuche Sie noch haben, kann dies kein Risiko darstellen (z. B. PIN in Ihrer Smartcard, um Anrufe zu tätigen). In anderen Situationen kann dies ein Risiko sein (z. B. Versuch, dies zu tun) Brute-Force-Handyzugriff), bei dem Sie vor dem letzten Versuch anhalten und einige Zeit warten können, damit der Benutzer den Zähler mit einem gültigen Zugriff zurücksetzt ...

Sie sollten das Ziel der Sicherheitskontrolle überprüfen, was Sie versuchen zu schützen und welche Sicherheitskontrollen Sie eingerichtet haben, um abnormale Situationen zu kompensieren oder zumindest zu überwachen.

Auf dieser Grundlage können Sie entscheiden, ob es sich um ein akzeptables Risiko für Ihre Besonderheiten handelt oder nicht.

Irgendwann war ich in einer Firma, in der nur ein paar Leute ihre Sicherheit testen mussten. Eines dieser Dinge, die diese Leute gefunden haben, ist, dass es keine Kontosperrung gab, wenn zu viele falsche Passwörter vorhanden waren. Zur großen Freude des CISO konnten sie jedoch nicht beweisen, dass sie tatsächlich einsteigen konnten, indem sie das Passwort brutal erzwangen. Der Grund dafür war, dass die Kontosperrung still war und etwa 15 Minuten dauerte.

Fragen Sie sich, was Sie durch die Anzeige einer solchen Nachricht gewinnen und was Sie dadurch an Sicherheit verlieren. Es ist absolut gültig, keine Benachrichtigung über das Sperren eines Kontos aufgrund zu vieler falscher Anmeldeversuche zu geben. Wenn Sie eine solche Nachricht geben, helfen Sie einem Angreifer nur dabei, herauszufinden, wann er seine Zeit mit brutaler Gewalt verschwendet. Wenn Sie dies nicht tun, ist es weniger wahrscheinlich, dass sie es herausfinden, aber es kann zu mehr Anrufen / E-Mails an Ihren Helpdesk führen, was kostspielig sein kann. Eine FAQ oder Hilfeseite kann dies reduzieren.

Auch die Implementierung des Countdowns bedeutet wahrscheinlich mehr Code und mehr Code bedeutet mehr Fehler. Dies ist nicht etwas, was Sie in einem Sicherheitsmechanismus wollen. Fügen Sie hinzu, dass Sie es falsch implementieren. Dadurch können Angreifer möglicherweise Benutzernamen aufzählen, was doppelt problematisch ist, wenn es sich um E-Mail-Adressen handelt. Zum Teufel, wenn Sie es mit einem nicht signierten Cookie implementieren, kann es dem Angreifer tatsächlich die Möglichkeit geben, eine Sperrung zu verhindern.

Im Allgemeinen wird Ihre Sicherheit verbessert, wenn Ihre Fehlermeldungen so wenig Informationen wie möglich enthalten .