Das Verhindern der Anmeldung ohne das richtige Kennwort ist die Kernfunktionalität des Anmeldevorgangs. Nur so weiterzumachen ist keineswegs eine "zusätzliche" Sicherheitsfunktion.

Anmeldeversuche nach X falschen Versuchen abzulehnen bedeutet, alle Versuche in dieser Situation abzulehnen, unabhängig vom Wert von das Passwort, das dann angezeigt wird. Wenn Sie immer noch das richtige Passwort akzeptieren, leugnen Sie nichts, sondern verwalten lediglich einen Anmeldevorgang.

Bei Online-Systemen ist das Deaktivieren des Kontos etwas unüberlegt. Dies bedeutet, dass jeder Ihr Konto effektiv blockieren kann, indem er Junk-Passwörter eingibt. Eine reibungslosere Vorgehensweise besteht darin, Verzögerungen hinzuzufügen: Lassen Sie den Server nach X falschen Kennwörtern das Konto beispielsweise für eine Minute sperren und nach jedem Versuch für eine Minute erneut sperren, bis das richtige Kennwort eingegeben wird. Die ersten X-Versuche sollten ausreichen, um Benutzer mit zitternden Fingern zu bewältigen, und die Geschwindigkeit von einer Minute behindert einen Bruteforcing-Angreifer erheblich (verbunden mit einigen Sicherheitsmaßnahmen wie dem Verbot von IPs, von denen zu viele Anmeldeanfragen in zu kurzer Zeit eingehen). .

Die Idee ist, beim Sperren nicht einmal das richtige Passwort zu akzeptieren.

Bevor Sie jedoch ein Sperrsystem implementieren, sollten Sie sich die Angriffsfälle ansehen:

a Bestimmter Benutzer wird angesprochen

Wenn der Angreifer auf einen bestimmten Benutzer abzielt, ist es hilfreich, Anmeldungen nach einigen falschen Versuchen zu verweigern oder zu verzögern. Ein häufiger Fehler beim Verzögerungsansatz besteht darin, parallele Anmeldeversuche nicht zu verhindern.

Ein weiterer häufiger Ansatz ist die Verwendung von CAPTCHAs, um den Angreifer zu verlangsamen. Man muss bedenken, dass viele Standard-CAPTCHAs bereits kaputt sind. Als die Abstimmung in der NY-Times manipuliert wurde, erstellten die Angreifer eine spezielle Oberfläche, auf der viele CAPTCHAs auf einer Seite angezeigt werden.

Der Angreifer versucht möglicherweise über einen langen Zeitraum hinweg nur zwei Anmeldeversuche pro Tag (wir sehen tatsächlich dies in Stendhal von Zeit zu Zeit). Hier kann es hilfreich sein, die Anzahl der fehlgeschlagenen Anmeldeversuche nach einer erfolgreichen Anmeldung anzuzeigen. Es ist wichtig, nicht jedes Mal "0 fehlgeschlagene Anmeldeversuche" zu sagen, da dies die Benutzer lediglich lehrt, diese Nachricht zu ignorieren. Zeigen Sie die Warnung nur an, wenn mindestens ein Anmeldeversuch fehlgeschlagen ist.

Eine Liste der IP-Adressen und Zeitstempel der letzten Anmeldeversuche (erfolgreich oder nicht) kann hilfreich sein, zumindest für Benutzer, die Wert auf Sicherheit legen und haben einen bestimmten Kenntnisstand.

Jeder Benutzer ist ein Ziel

In Fällen, in denen eine wirklich große Anzahl von Anmeldungen versucht wird, wählen die Angreifer häufig ein festes Passwort und erzwingen das brutal Kontonamen. Dies bedeutet, dass ein Schwellenwert von drei Anmeldeversuchen pro Konto nicht ausgelöst wird.

Fehlgeschlagene Anmeldeversuche müssen daher kontenübergreifend verfolgt werden, z. B. basierend auf den IP-Adressen.

Sperren einer großen Anzahl von Benutzern

Das Implementieren der oben genannten Zählermessungen führt zu einer neuen Sicherheitsanfälligkeit: Ein Angreifer kann eine große Anzahl von Konten sperren. In einigen Fällen kann dies einer Site weitaus größeren Schaden zufügen als einer kleinen Anzahl gehackter Konten.

IP-basiertes Zählen kann helfen, diesen Angriffsvektor zu verringern. Oder es kann einen Hebel in Situationen geben, in denen sich viele Personen hinter demselben Proxyserver befinden (an einer Universität oder in einem öffentlichen WLAN usw.).

Sperren eines bestimmten Kontos

Zusätzlich zum letzten Abschnitt kann ein Angreifer versuchen, ein bestimmtes Konto zu sperren. Zum Beispiel jemand, der bei einer Auktion gegen ihn bietet.

Möglicherweise kann ein zweiter Kanal verwendet werden, damit der Kontoinhaber sein Konto wieder aktivieren kann. Zum Beispiel durch Senden einer mobilen Textnachricht oder einer E-Mail mit einem Code.

Ich mag die Antwort von Thomas Pornin. Meine einzige Ergänzung wäre: Wenn Sie eine Kennwortsperrfunktion entwerfen, müssen Sie herausfinden, wie Sie Ihre Benutzerbasis unterstützen und dies mit dem Risiko von Unterbrechungen in Einklang bringen können.

In einem Hochsicherheitssystem mit einer begrenzten Anzahl Für sicherheitsbewusste Benutzer, dedizierte Administratoren und ein großes Budget für die Benutzerunterstützung kann die Aktivierung eines gesperrten Kennworts manuell erfolgen und eine erneute Authentifizierung über einen sekundären Kanal erfordern, der teuer und zeitaufwändig ist.

In Bei einem System mit geringer Sicherheit und einer riesigen (und möglicherweise sogar Computer-Analphabeten-) Nutzerbasis - wie Google oder Hotmail - wird das Risiko eines Einbruchs wahrscheinlich durch die Kosten für die Unterstützung der Konto-Freischaltung durch etwas anderes als eine hochautomatisierte, sehr einfache ausgeschlossen , process.

Ich habe Systeme gesehen, die so einfach waren, dass sie den Browser nur zwangsweise geschlossen haben, als 3 falsche Passwörter erreicht wurden. Etwas besser ist das von Thomas vorgeschlagene System mit einer Zeitüberschreitung für deaktivierte Konten. Nach meiner Erfahrung stellen Systeme dies dar, um eine moderate Barriere für Bruteforce-Angriffe zu bieten und gleichzeitig die Bedürfnisse von Tonnen von Benutzern auszugleichen, die versuchen, auf ihre Konten zuzugreifen.

Es ist wahr, dass dies nicht der beste Ansatz ist - aber Systeme benötigen Um einen Weg zu finden, um Angriffe zu verlangsamen, ohne sich persönlich mit Benutzern zu befassen, kostet jeder Supportanruf den Anbieter Geld. Mit kostenlosen Diensten wie Google Mail erhalten Sie also das, wofür Sie bezahlen.

Ich würde vorschlagen, dass Sie nicht nur ein Benutzerprofil sperren, das zu viele falsche Passwörter erhält, sondern auch die IP eines Computers blockieren, der zu viele falsche Passwörter erhält (möglicherweise mit mehreren Konten).

Ich verwende DenyHosts auf meinen Linux-Computern, um IPs zu blockieren, die versuchen, Passwörter zu erraten.

Ich denke, Sie sollten den Benutzer bestimmen lassen, wie "zufällig" sein Passwort ist.

Bei einigen "Passwörtern" ist es einfach nicht sinnvoll, ein Limit festzulegen : Einige Benutzer generieren ihre "Passwörter" automatisch (was es unmöglich macht, sie sich zu merken) und speichern diese in einer Datei, sodass diese Passwörter eher Kryptoschlüsseln als normalen Passwörtern ähneln.

Ich glaube, dass das zulässt Der Benutzer wählt aus, wie viele Versuche, bevor das Konto eine Anmeldezeitstrafe von 10 s, 30 s, 1 min erhält, und wie viele, bevor das Konto für 1 h, 12 h, 1 d mit oder ohne CAPTCHA-Rückgriff strong gesperrt wird > würde den Benutzer zwingen, mehr über die Stärke seines Passworts nachzudenken.

Dann geben Sie nicht nur den Menschen etwas Freiheit, Sie erzwingen diese Freiheit den Benutzern : Jeder Benutzer würde Sie müssen eine Sperrrichtlinie auswählen.

Außerdem sollte es einem Benutzer gestattet sein, sein Konto mit einer RBL zu verknüpfen, um zu verhindern, dass die Anmeldung von offenen SOCKS-Relays oder von Tor-Exits erfolgt (standardmäßig ist keine RBL abonniert).

Für Webanwendungen a Der Benutzer sollte das Recht haben, zwischen einer reinen HTTP-basierten Authentifizierung (HTTP-Authentifizierung, Cookies, ...) oder einer HTTP-basierten + IP-Adr-basierten Authentifizierung (Bindung eines angemeldeten Benutzers an eine IP) zu wählen (standardmäßig nur HTTP) -basierte Authentifizierung, keine IP-Adr-Bindung).

Ich denke, Sie sollten den Benutzern aggressiv Freiheit und Verantwortung geben. Auf diese Weise können sie nicht in Foren weinen, wenn sie gehackt wurden, und sagen, dass das Kennwort System-Setup schwach, unsicher, nicht professionell war ...

Es hängt stark davon ab, auf welche Art von Konto der Benutzer zugreifen möchte. Webbasierte E-Mail-Konten sind das übliche Beispiel, bei dem die E-Mail der Benutzername ist. In anderen Fällen ist es jedoch besser, die E-Mail nicht als Benutzernamen zu verwenden. Daher verfügt der Angreifer nicht über die Benutzeranmeldeinformationen, um das Kennwort im Wörterbuch zu knacken

Jede Form der Kontosperrung ohne Captchas oder eine andere Form der Massen-POST-Verhinderung kann zu Denial-of-Service führen, wenn ein Angriffstool verwendet wird, um mehrere Anforderungen zu senden, um Kontosperren zu verursachen.

Die Verwendung von Nicht-E-Mails oder Namen ist der Standard bei Website-Konto-Anmeldungen wie Godaddy und anderen sowie bei Bankkonto-Anmeldungen, obwohl dies in der Regel Zahlenfolgen sind, die sie für benutzerspezifische Denial-of-Service-Angriffe öffnen über Massen-Brute-Force-Angriffe auf Zahlenfolgenblöcke.

Beispiel: Benutzer: 1000000 ++ Pass: a-zA-Z0-9

Ein Angriff, der 4 Versuche auf einen sequentiellen Benutzernamen sendet, wobei Die Bank hat den Benutzer auf einen Zahlenbereich festgelegt, wie er 48829387 leicht zulassen könnte n Angreifer, der Anmeldungen bei einer großen Anzahl von Bankbenutzern verweigert, indem er die Grenze zulässiger falscher Kennwortanforderungen für Zufallszahlen zwischen den Bereichen 4000000 und 4999999 überschreitet.

In den meisten Web-Anmeldesituationen jedoch Benutzer Wenn Sie einen Benutzernamen wählen, der von ihrem Namen oder ihrer E-Mail-Adresse getrennt ist, ist dies eine große Herausforderung. Dies ist wahrscheinlich der Grund, warum Banken häufig Zahlenfolgen als Benutzernamen verwenden.

Wenn also keine schwierigen Benutzernamen als Option verfügbar sind, können Sie das Hämmern des Wörterbuchs verhindern ist die nächste Anlaufstelle für die Verwendung von Captchas oder sogar für die Anforderung von Javascript vor dem Einrichten von Sitzungen, da diese Angriffstools vom Typ Wörterbuch häufig nicht in der Lage sind, zurückgegebene Cookies zu verarbeiten, geschweige denn Sitzungen, die nach dem Erkennen von Javascript erstellt wurden.