it-swarm.com.de

Was sind die Sicherheitsrisiken beim Protokollieren des Hash abgelehnter Passwörter?

Laut Ist es üblich, abgelehnte Passwörter zu protokollieren? weiß ich, dass das Protokollieren abgelehnter Nur-Text-Passwörter eine schlechte Idee ist, aber wie wäre es, wenn ich die Hash-Form abgelehnter Passwörter speichere? Ich möchte weitere Informationen über das fehlgeschlagene Login zur Analyse erhalten, z. B.:

  1. Überprüfen Sie, ob es sich nur um einen Tippfehler handelt: Wenn ein Benutzer beim ersten Mal häufig mit demselben Hash-Passwort fehlgeschlagen ist, sich aber später erfolgreich anmeldet, handelt es sich möglicherweise nur um einen Tippfehler

  2. Überprüfen Sie, ob jemand versucht, ein Kennwort zu erraten: Einige gängige Kennwörter, z. B. 123456 und Geburtstag, bei denen der Hash behoben wurde. Wenn diese Versuche vorhanden sind, kann die fehlgeschlagene Anmeldung von Kennwortschätzern durchgeführt werden.

  3. Überprüfen Sie, ob ein Benutzer ein alternatives Konto hat: Einige Benutzer haben möglicherweise ein alternatives Konto, jedoch mit unterschiedlichen Kennwörtern. Wenn sich ein Benutzer normalerweise nicht mit demselben Hash anmeldet und der Hash mit einem anderen Konto identisch ist, sich dann jedoch erfolgreich anmeldet, kann es sich um ein Konto handeln Benutzer, der versucht, sich mit einem alternativen Konto anzumelden, aber vergessen hat, das Passwort zu wechseln.

Meine Frage ist, hat das Protokollieren der Hash-Form von abgelehnten Passwörtern das gleiche Problem wie das Protokollieren von abgelehnten Klartext-Passwörtern?

36
ocomfd

Wenn richtig gehasht (d. H. Mit zufälligem Salz und starkem Hash) ist ein gehashtes Passwort nicht umkehrbar und gehashte Passwörter für verschiedene Konten unterscheiden sich, selbst wenn die Passwörter gleich sind.

Dies bedeutet, dass fast keine der Analysen, die Sie durchführen möchten, mit den ordnungsgemäß gehashten (dh zufälligen Salt-) Passwörtern durchgeführt werden kann, dh Sie gewinnen fast nichts durch das Protokollieren von Passwörtern und verlieren höchstens, da Sie einige Informationen an Stellen verlieren Hier kann ein Angreifer möglicherweise leichter darauf zugreifen, da Protokolle normalerweise nicht so vertraulich sind wie gespeicherte Kennwörter.

Wenn Sie stattdessen einen einfachen Hash (kein Salz) verwenden, sind einige der von Ihnen erwähnten Dinge auf Kosten eines erhöhten Angriffsvektors möglich, da ein Angreifer jetzt vorberechnete Hash-Tabellen verwenden kann, um Ihre protokollierten Kennwörter umzukehren.

Vielleicht haben Sie einige Missverständnisse darüber, was richtiges Passwort-Hashing bedeutet. Ich empfehle das Lesen von Wie werden Passwörter sicher gehasht? , um eine Vorstellung davon zu bekommen, wie das richtige Passwort-Hashing durchgeführt wird und warum dies auf diese Weise erfolgt. Im Folgenden werde ich jedoch einige der Missverständnisse ansprechen, die Sie anscheinend haben:

Überprüfen Sie, ob es sich nur um einen Tippfehler handelt: Wenn ein Benutzer beim ersten Mal häufig mit demselben Hash-Passwort nicht angemeldet ist, sich aber später erfolgreich anmeldet, handelt es sich möglicherweise nur um einen Tippfehler

Sie können einen Tippfehler nicht mit den Hash-Passwörtern überprüfen, da bereits eine kleine Änderung der Eingabe zu einer großen Änderung der Ausgabe führt. Sie können auch nicht in den ursprünglichen Passwörtern nach Tippfehlern suchen, da Sie den Hash nicht umkehren können, um das Passwort zum Vergleich zu erhalten. Um zu überprüfen, ob das eingegebene falsche Passwort immer das gleiche ist, können Sie den Hash protokollieren, der mit dem gleichen Salz gesalzen ist wie das gespeicherte (korrekte) Passwort, wie Jon Bentley in einem Kommentar vorgeschlagen hat. Wenn die Protokolle mindestens so gut geschützt sind wie die gespeicherten Passwörter, würde dies die Angriffsfläche nur geringfügig vergrößern, aber wie gesagt, Protokolle werden normalerweise nicht als so sensibel angesehen wie das Speichern von Passwörtern.

... Einige gebräuchliche Passwörter, wie 123456 und Geburtstag, bei denen Hash behoben wurde, ...

Beim richtigen Passwort-Hashing wird ein zufälliges Salz verwendet, um Angriffe mit vorberechneten Hashes mit gängigen Passwörtern unmöglich zu machen. Dies bedeutet, dass dasselbe Kennwort zu einem anderen Hash führt, wenn es gehasht wird, d. H. Ihre Annahme, dass diese Kennwörter einen festen Hash haben, ist falsch. Auch hier könnten Sie die einfacheren, ungesalzenen Hashes auf Kosten einer erhöhten Angriffsfläche rückgängig machen.

Es ist möglicherweise besser, diese Art der Analyse durchzuführen, wenn das eingegebene Kennwort noch verfügbar ist, und nur das Ergebnis dieser Analyse zu protokollieren.

... wenn sich ein Benutzer normalerweise nicht mit demselben Hash anmelden konnte und der Hash mit einem anderen Konto identisch ist, sich dann aber erfolgreich anmeldet, ...

Da sich die Hashes für dasselbe Passwort unterscheiden, benötigen Sie das ursprünglich eingegebene Passwort, um diese Art von Vergleich durchzuführen. Da Sie dies nicht vom protokollierten Hash zurückerhalten können, hilft es nicht, das Hash-Passwort protokollieren zu lassen. Auch hier könnten Sie diese Art der Analyse mit ungesalzenen Hashes durchführen. Dies würde jedoch bedeuten, dass für alle Ihre Konten das Kennwort auf unsichere ungesalzene Weise verfügbar sein muss - was eine große Zunahme der Angriffsfläche darstellt. Sie könnten diese Art der Analyse wahrscheinlich auch mit gesalzenen Passwörtern durchführen, müssten dann aber die neu eingegebenen Passwörter mit allen derzeit verwendeten Salzen (d. H. Einer für jedes Konto) salzen.

100
Steffen Ullrich

Dies ist keine gängige Praxis und widerspricht im Allgemeinen der Sicherheit. IMHO, keiner der Gründe, die Sie auflisten, ist gut genug, um gehashte Passwörter zu protokollieren. Tatsächlich kann ich mir keinen guten Grund vorstellen, sie zu protokollieren. Möglicherweise treten Compliance-/Gesetzgebungsprobleme auf (z. B. PCI). Benutzer versagen Kennwörter normalerweise durch Tippfehler und vergessen, welches Kennwort sie für welche Site usw. verwendet haben. Sie haben diese Kennwörter auch an einem anderen Ort als Ihrer Datenbank, sogar auf einem Remote-Server, wenn Sie eine Art Protokollierung über Syslog verwenden.

Keiner dieser Gründe ist der Grund, gehashte Passwörter zu protokollieren. Um Ihre Frage direkt zu beantworten, ist es „besser“, Hash-Passwörter im Vergleich zu Klartext-Passwörtern zu protokollieren, aber beide sind sehr schlecht und sollten nicht durchgeführt werden.

Beispiel: Ein Teil von HIPPA konzentriert sich auf die Notwendigkeit, elektronische geschützte Gesundheitsinformationen (ePHI) angemessen und effektiv zu schützen, indem gute und Standardpraktiken eingehalten werden. Laut dem Auditor, mit dem ich arbeite, würden Sie beim Protokollieren von Passwörtern (gehasht oder auf andere Weise) als unvollständig eingestuft, da dies keine empfohlene und übliche Vorgehensweise ist.

17
pm1391

Sie machen viele Annahmen über:

  • Die Nützlichkeit dieser Aktionen.
  • Das Hashing und Speichern der Passwörter ist der einzige Weg, um diese Aktionen zu erreichen.
  • Sogar, dass einige dieser Aktionen von einem richtig gesalzenen und gehashten Passwort abgeleitet werden können.

Wenn ein Benutzer eine Anmeldung nicht besteht, kann dies viele Gründe haben. Dies kann beispielsweise daran liegen, dass sie mehrere Kennwörter haben und diese durchlaufen und sich fragen, welche sie auf der Site verwendet haben. Jetzt haben Sie einen (gesalzenen) Hash des Benutzerkennworts für diese eine Site gespeichert und möglicherweise mehrere (gesalzene) ) Hash-Passwörter, die der Benutzer tendenziell verwendet. Ebenso habe ich bei E-Mails mehrere E-Mails, die ich verwende. Ich kann mich möglicherweise nicht erinnern, welche ich für die Website verwendet habe. Jetzt speichern Sie meine E-Mails, um sie zu korrelieren (dieser Teil hängt von Ihrer Korrelation des Kennworts mit der Benutzerlogik ab). Grundsätzlich erstellen Sie ein Kompendium aus Benutzernamen/E-Mails und Kennwortkombinationen für einen potenziellen zukünftigen Gegner Ihrer Website. Einige Ihrer Ideen:

"Überprüfen Sie, ob es nur Tippfehler ist"

Wieso kümmert es dich? Wenn es sich um einen Tippfehler handelt, hat der Benutzer einen Tippfehler gemacht und ihn herausgefunden. Wenn es Ihr Ziel ist, Fingerabdrücke zu entwickeln, um einem Angreifer das brutale Forcen zu erklären, gibt es andere Möglichkeiten. Dies ist auch mit einem richtig gesalzenen und gehashten Passwort nicht möglich. Das ist genau das Ziel des Salzens und Haschens. Sie selbst sollten nicht in der Lage sein, den ursprünglichen Klartext ohne großen Aufwand rückzuentwickeln. Wenn Sie keinen einfachen Text haben und der Hashing-Algorithmus gut ist, können Sie nicht feststellen, ob ein Tippfehler gemacht wurde.

"Überprüfen Sie, ob jemand versucht, das Passwort zu erraten."

Stellen Sie zunächst sicher, dass die tatsächlichen Benutzer nicht über diese Kennwörter verfügen. Zweitens gibt es andere Methoden. Drittens, wenn Sie wirklich wollten, können Sie die Eingabe im Stream hashen und mit Hashes bekannter schwacher Passwörter vergleichen. Wenn dies der Fall ist, müssen Sie protokollieren, dass sie übereinstimmen. Es ist nicht erforderlich, das Passwort in irgendeiner Form selbst zu protokollieren.

"Überprüfen Sie, ob ein Benutzer ein alternatives Konto hat"

Sofern Sie keinen expliziten Grund dafür haben, was gegen Ihre Bestimmungen verstößt, ist dies vom Standpunkt des Benutzers aus nicht erforderlich. Darüber hinaus ist ein ordnungsgemäß gesalzenes und gehashtes Kennwort nicht sofort mit anderen Datensätzen in Ihrem System vergleichbar. Dies ist der Punkt des Salzens, sodass vorberechnete Hashes verschiedener Klartext-Eingaben nicht abgeglichen werden können. Wenn also jemand dasselbe Passwort für zwei verschiedene Konten hatte, stimmt dieser Hash mit der Vorstellung, dass das hinzugefügte Salz zufällig ist, nicht überein. Selbst wenn sie übereinstimmen, kann es sich um einen völlig anderen Benutzer mit demselben Kennwort oder einem Kennwort handeln, das nur ein Zeichen entfernt ist (Tippfehler oder Kennwortvariation).

Die Idee verstößt so ziemlich gegen jeden existierenden Sicherheitsbegriff. Ich würde es nicht empfehlen.

13

Steffens Antwort ist genau richtig, aber ich denke, es ist wichtig zu wissen, dass Sie andere Optionen haben, ohne die Hash-Passwörter zu protokollieren. Meine Antworten setzen voraus, dass Sie eine externe Website mit einem Login betreiben. Wenn es intern ist, können Sie fast alles über den Computer/das Gerät speichern, auf dem/dem sie angemeldet sind.

Überprüfen Sie, ob es sich nur um einen Tippfehler handelt: Wenn ein Benutzer beim ersten Mal häufig mit demselben Hash-Passwort nicht angemeldet ist, sich aber später erfolgreich anmeldet, handelt es sich möglicherweise nur um einen Tippfehler

Melden Sie sich einfach an, wenn ein Benutzer ausfällt und erfolgreich ist. Sie können Berichte ausführen und feststellen, ob ein Benutzer bei der ersten Anmeldung häufig fehlschlägt.

Überprüfen Sie, ob jemand versucht, ein Kennwort zu erraten: Einige gängige Kennwörter, z. B. 123456 und Birthday, bei denen der Hash behoben wurde. Wenn diese Versuche vorhanden sind, kann die fehlgeschlagene Anmeldung von Kennwortschätzern durchgeführt werden.

Protokollieren Sie die IP-Adressen von Anmeldeversuchen. Dies ist zwar eine gängige Praxis, Sie müssen jedoch sicherstellen, dass Sie dies an den von Ihnen betriebenen Orten auf legale Weise tun. Viele Websites erfordern zusätzliche Informationen, wenn Sie sich an einem unbekannten Ort anmelden.

Überprüfen Sie, ob ein Benutzer ein alternatives Konto hat: Einige Benutzer haben möglicherweise ein alternatives Konto, jedoch mit unterschiedlichen Kennwörtern. Wenn sich ein Benutzer normalerweise nicht mit demselben Hash anmeldet und der Hash mit einem anderen Konto identisch ist, sich dann jedoch erfolgreich anmeldet, kann es sich um ein Konto handeln Benutzer, der versucht, sich mit einem alternativen Konto anzumelden, aber vergessen hat, das Passwort zu wechseln.

Dies scheint eine Kombination der beiden anderen Antworten zu sein.

5
MiniRagnarok

Sie können das erreichen, was Sie wollen, ohne die Kennwortprotokollierung. Es ist aber auch wichtig zu fragen, warum. Warum machen diese Prüfungen? Was machen Sie realistisch mit diesen Informationen? Können sie mit passiven Mitteln erreicht werden?

Überprüfen Sie, ob es sich nur um einen Tippfehler handelt: Wenn ein Benutzer beim ersten Mal häufig mit demselben Hash-Passwort nicht angemeldet ist, sich aber später erfolgreich anmeldet, handelt es sich möglicherweise nur um einen Tippfehler

Überprüfen Sie, ob jemand versucht, ein Kennwort zu erraten: Einige gängige Kennwörter, z. B. 123456 und Birthday, bei denen der Hash behoben wurde. Wenn diese Versuche vorhanden sind, kann die fehlgeschlagene Anmeldung von Kennwortschätzern durchgeführt werden.

Es reicht aus, das Konto, den Zeitstempel, die IP-Adresse und den Erfolg zu protokollieren. Aus diesen Informationen können Sie viel ableiten.

Wenn Sie ein Muster von fehlgeschlagen, fehlgeschlagen, fehlgeschlagen, schnell hintereinander für dasselbe Konto übergeben, war es wahrscheinlich ein Tippfehler. Wenn Sie sehr viele Fehler hintereinander und sehr schnell sehen, ist dies wahrscheinlich ein Angriff auf dieses Konto.

Ein intelligenter Angreifer spielt jedoch das Zahlenspiel und verteilt seine Angriffe auf mehrere Konten. Wenn der Angreifer keine Informationen zu Ihren Konten hat, funktioniert eine bestimmte Kennwortschätzung genauso wahrscheinlich für ein bestimmtes Konto. Wenn sie 100 Passwörter zum Ausprobieren haben, spielt es keine Rolle, ob sie alle auf einem Konto testen oder auf 100 Konten verteilen, die Chancen sind gleich.

Ebenso können sie mehrere IP-Adressen verwenden. Wenn Sie eine Gruppe von fast allen Fehlern von vielen Konten sehen, aber eine einzelne IP, die ein verteilter Angriff sein könnte, oder eine Gruppe von echten Benutzern hinter demselben NAT oder VPN. Es ist schwierig erzählen.

Realistisch gesehen gibt es einen viel einfacheren Weg. Diese Angriffe werden durch Ratenbegrenzung und Soft Lockouts teurer. Das Erraten eines Passworts hängt davon ab, dass sehr viele Anmeldeversuche sehr schnell durchgeführt werden können. Die Rate der Anmeldungen sollte bereits durch das Konto begrenzt sein. Es gibt keinen Grund, warum ein echter Benutzer mehrmals pro Sekunde versucht, sich anzumelden. Wählen Sie das höchstmögliche Ratenlimit aus, das von Ihren Benutzern immer noch nicht wahrgenommen wird. Dies verhindert schnelle automatische Anmeldeversuche. Wenn es ohnehin anhaltende Versuche gibt, erhöhen Sie automatisch und exponentiell das Ratenlimit für dieses Konto (und möglicherweise IP), und reduzieren Sie es, sobald die angeblichen Tests nachlassen.

Darüber hinaus können Sie beim Erstellen ihrer Konten ein gutes Feedback zur Kennwortstärke geben, um leicht zu erratende Kennwörter zu vermeiden.

Auf diese Weise können Sie automatisierte Schnellfeuersonden vereiteln, ohne legitime Benutzer zu ärgern, die es heute nur schwer haben zu tippen.

Überprüfen Sie, ob ein Benutzer ein alternatives Konto hat: Einige Benutzer haben möglicherweise ein alternatives Konto, jedoch mit unterschiedlichen Kennwörtern. Wenn sich ein Benutzer normalerweise nicht mit demselben Hash anmeldet und der Hash mit einem anderen Konto identisch ist, sich dann jedoch erfolgreich anmeldet, kann es sich um ein Konto handeln Benutzer, der versucht, sich mit einem alternativen Konto anzumelden, aber vergessen hat, das Passwort zu wechseln.

Dies scheint eher eine Geschäftsanforderung als ein Sicherheitsproblem zu sein. Sie versuchen im Wesentlichen, die eindeutige Person hinter einem Konto zu erkennen, und das ist ziemlich schwer zu finden: Das Internet möchte sehr, dass Sie diese Informationen nicht haben. Die Kosten, um es richtig zu machen, sind hoch, und da Sie immer mehr Benutzer haben, ist es immer wahrscheinlicher, dass viele Fehlalarme Ihre echten Benutzer stören.

Wenn Sie beispielsweise ein Data Mining-Unternehmen sind, sollten Sie sich überlegen, warum Sie diese Anforderung haben: Welche tatsächlichen Auswirkungen hat dies auf Ihr System? Welche Metriken müssen Sie dafür sichern?

Wenn Sie sich wirklich dazu entschließen, Alts zu verhindern, verwenden Sie verschiedene halb eindeutige IDs aus der realen Welt, um Alt-Konten Kosten hinzuzufügen und deren Häufigkeit zu verringern. E-Mail-Adresse ist die häufigste. Das Erstellen von Konten kostet Geld oder das Erfordernis einer Kreditkartennummer ist eine andere. Sogar Steueridentifikationsnummern, wenn Sie ein großes Unternehmen sind. Es hängt alles davon ab, was Sie tun.

1
Schwern

Ist das übliche Praxis, sicherlich nicht; ist es eine gute Praxis, wahrscheinlich nicht. Ich habe dies jedoch einmal gesehen, und um eine vollständige Diskussion über das Thema zu führen, möchte ich hier gegen den Strich gehen und sagen, wofür es nützlich sein kann und welche Vorkehrungen getroffen wurden, um die von anderen festgestellten Probleme zu vermeiden.

Vor dem Hintergrund unablässiger externer Angriffe auf bekannte Anmeldungen, Brute Force, Wörterbuchangriffe, Angriffe mit einem Kennwort für jeden Benutzer, Spearphishing und Malware zum Aufspüren von Kennwörtern hatte das Unternehmen schwerwiegende Probleme mit Mobiltelefonen, Tablets und Kennwörtern Veränderung.

Wenn die mobile Sitzung nach einer Kennwortänderung zurückgesetzt wurde, versuchten die Mobiltelefone in der Regel mehrmals das Kennwort alt, Bevor sie aufgaben, normalerweise ein Vielfaches von drei (möglicherweise E-Mail, Kalender, Aufgaben oder ähnliches) dass), vorher den Benutzer zur Eingabe eines neuen Passworts auffordert. Dadurch wurde das Benutzerkonto aufgrund einer administrativ und technisch nicht verhandelbaren Drei-Treffer-Regel für das Authentifizierungs-Backend gesperrt.

Es ist sehr wahrscheinlich, dass dieses Verhalten mobiler Geräte seitdem korrigiert wurde (dies war vor einigen Jahren), und ich würde mich interessieren, ob dies der Fall ist.

Kurz gesagt, Benutzer haben jeden Monat ein "Passwort ändern" auf ihrem Desktop erhalten, und diejenigen, die das Passwort nicht sofort auf all ihren Mobilgeräten geändert haben Auf allen Geräten gesperrt, auch auf Geräten, die mit dem (sichereren) internen Netzwerk verbunden sind. Dies war ein schwerwiegenderes Problem als das "bloße" Sperren aus dem Internet. Manchmal reichte es nicht sofort aus, und es gab eine Prozedur mit einem komplizierten Tanz im Flugzeugmodus, um nicht ausgesperrt zu werden. Benutzer mit Handy und Tablet hatten natürlich noch mehr Probleme.

Die Organisation hat die Protokollierung des Hash-Passworts folgendermaßen implementiert:

  • als Ebene zwischen der Anwendung und dem Authentifizierungs-Backend eingefügt.
  • hashing mit PBKDF2.
  • ein Salz von Mitternacht bis Mitternacht, ein Salz von Mittag bis Mittag, zwei Hashes für jede Anmeldung gespeichert. Das Salz wurde in der Schicht aufbewahrt und nirgendwo anders gespeichert (ein Neustart der Schicht bedeutete ein neues Salz, und als das Salz regeneriert wurde, ging es verloren, da es nicht im Hash gespeichert wurde, wie z bcrypt hätte getan).
  • pfeffer mit Login (was bedeutet, dass identische Passwörter für verschiedene Konten nicht erkennbar waren).
  • in einer bestimmten (nicht auf Helpdesk zugänglichen) Datenbank gespeichert und (optional) in einem bestimmten Datenspeicher im Formularfehler (Datum, Benutzer, Quell-IP, Hash1, Hash2, Benutzeragent ...) und Erfolg (Datum, Benutzer, Quelle) protokolliert IP, useragent ...).
  • die Datenbank verwendete eine API, die alle Aktionen verbietet, die hier nicht speziell aufgeführt sind (z. B. das Auflisten von Hashes für alle Benutzer).
  • nach Erhalt einer Authentifizierungsanforderung:
    • überprüfen Sie in der Datenbank, ob ein Kennwort mit demselben Hash für diesen Benutzer abgelehnt wurde (in den letzten 24 Stunden), und lehnen Sie in diesem Fall die Anmeldung ab, ohne die Authentifizierungsanforderung an das Backend zu senden, und protokollieren Sie diesen Grund im Helpdesk, auf den zugegriffen werden kann Protokolle (ohne Hash).
    • überprüfen Sie in der Datenbank, ob dieselbe Quell-IP in den letzten n Stunden die Authentifizierung für mehrere Benutzerkonten ohne erfolgreiche Anmeldungen fehlgeschlagen ist. Wenn dies der Fall ist, lehnen Sie die Anmeldung ab, ohne die Authentifizierungsanforderung im Backend vorzulegen, und melden Sie sich aus diesem Grund an die Helpdesk-zugänglichen Protokolle (immer noch ohne Hash).
    • andernfalls übergeben Sie die Anforderung an das Backend und protokollieren/speichern Sie das Ergebnis.
  • wenn das Benutzerkennwort geändert wird, löst das Authentifizierungs-Backend das Entfernen aller Datensätze für diesen Benutzer aus der Datenbank aus (wodurch die Tatsache protokolliert wird, dass das Kennwort geändert wurde). Dies war die einzige Änderung am Authentifizierungs-Backend.
  • datensätze, die älter als 24 Stunden sind, wurden aus der Datenbank gelöscht.
  • protokolle waren nur für die Sicherheitsprüfer zugänglich.
  • in dem Fall, in dem auf Protokolle zugegriffen wurde, entfernt die API für den Zugriff auf die Hashes die Hashes und zeigt nur Namen in der Form PASS1, PASS2 an. . . PASSN an den Sicherheitsprüfer. Der Zugriff auf die Rohdatenbank war äußerst eingeschränkt, im Wesentlichen nur durch die Vorlage der Anmeldeinformationen eines leitenden Entwicklers und eines Sicherheitsmanagers. Dies lag nicht wirklich am Vorhandensein der Hashes, sondern an der Sensibilität der Protokolle im Allgemeinen und war (ist) das Standardverfahren in der Organisation für den Zugriff auf Rohdatenbanken außerhalb der genehmigten API.
  • es wurde diskutiert, ob es notwendig ist, den Benutzernamen tatsächlich zu speichern. Die gleichen gewünschten Funktionen hätten wahrscheinlich ohne dies erreicht werden können, und dies hätte unnötige Benutzerverfolgung vermieden. Am Ende wurde es als wichtig erachtet zu wissen, ob ein Angreifer gezielt auf einen Benutzer abzielt oder Zugriff auf eine Benutzerliste hat.
  • es gab auch eine Funktion, die nicht vorhandene Benutzer auf sichere (gehashte) Weise protokollierte (ermöglicht durch das Authentifizierungs-Backend, das einen detaillierten Grund für eine Ablehnung zurückgibt), sodass ein externer Agent, der viele nicht vorhandene Benutzer ausprobiert, für einige ebenfalls auf die schwarze Liste gesetzt würde viel Zeit.

Kurz gesagt, das Konzept hinter dieser Implementierung war, dass Wörterbuchangriffe sind ein Problem, aber wiederholte Versuche mit demselben (falschen) Passwort stellen keinen Wörterbuchangriff dar.

Diese Implementierung:

  • erfolgreich vermieden, dass Benutzer gesperrt wurden wenn eines ihrer Geräte wiederholt dasselbe Kennwort versuchte, was das gewünschte und äußerst dringende Ziel war
  • verhinderte Brute-Force-Angriffe auf gemeinsame Kennwörter für mehrere Konten. Dies war keine Funktion, die das Authentifizierungs-Backend bereitstellen konnte
  • entkoppelte die Authentifizierung vom Internet vom internen System, sodass Angriffe vom Internet keine Auswirkungen auf die Benutzeranmeldung auf ihrer Workstation haben
  • stark reduzierte Anrufe beim Helpdesk zu diesem Thema
  • die Eskalation zu Tier 3 wurde erheblich reduziert, da Tier 2 nun Zugriff auf den Grund für die abgelehnte Authentifizierung für ein bestimmtes Konto hatte (mit dem Benutzeragenten, jedoch ohne Hashes).

Um die Frage zu beantworten. . . Sie geben mehrere Gründe für die Protokollierung der Hashes abgelehnter Kennwörter an. Wie Sie jedoch sehen, gilt dieses konkrete Beispiel für die tatsächliche Protokollierung der Hashes abgelehnter Kennwörter nicht für diese Gründe. Ich persönlich denke, dass die von Ihnen angegebenen Gründe nicht gültig sind.

  1. Überprüfen Sie, ob es sich nur um einen Tippfehler handelt: Solange sich ein Benutzer nach einer begrenzten Anzahl von Versuchen tatsächlich anmeldet, haben Sie kein Problem. Es kann ein Tippfehler oder ein altes Passwort oder das Passwort eines anderen Kontos sein, aber sollte es Sie interessieren?

  2. Überprüfen Sie, ob jemand versucht, das Passwort zu erraten: Ja, aber Sie tun dies nicht und sollten es nicht mit Hashes bekannter Passwörter vergleichen. Wenn Sie verhindern möchten, dass allgemeine Kennwörter verwendet werden, sollten Sie Regeln erzwingen, wenn der Benutzer ein Kennwort auswählt, und nicht danach.

  3. Überprüfen Sie, ob ein Benutzer über ein alternatives Konto verfügt: Das Verknüpfen von Konten kann möglicherweise über die Quell-IP erfolgen. Ich glaube jedoch nicht, dass das Wissen, dass ein Benutzer zuerst das Kennwort eines anderen Benutzers vor seinem eigenen versucht, dazu beiträgt, unbefugten Zugriff zu verhindern. Wenn Sie einen dringenden und rechtlichen Grund haben, um zu verhindern, dass Benutzer mehrere Konten haben, sollten Sie Quell-IPs, Geräte und Anmeldezeiten besser nachverfolgen als Fehler in Kennwörtern.

Durch die Identifizierung des Mobilgeräts hätte mehr erreicht werden können, aber die eigentliche Lösung war das Mobile Device Management und ein Hardware-MFA-Gerät für Desktop-Anmeldungen. Sobald sich die Situation stabilisiert hatte, war dies die Wahl der betreffenden Organisation.

Hoffe das hilft.

1
Law29

Wie aus mehreren Antworten in diesem Beitrag hervorgeht, ist es möglicherweise nicht praktikabel, fehlgeschlagene Kennwörter mit gespeicherten Kennwörtern (Hash) zu analysieren, um die Anwendungsfälle zu analysieren, die Sie aufgrund erweiterter Sicherheitsfunktionen wie "Salting" usw. angegeben haben.

Die eine der realen Anforderungen, die ich sehen kann, ist unten im HIPAA-Standard (Health Insurance Portability and Accountability Act), aber es besteht auch kein Bestehen darauf, die fehlgeschlagenen Passwörter aufzuzeichnen, sondern die anderen Informationen wie unten hervorgehoben aufzuzeichnen/zu überwachen:

Gemäß HIPAA-Standard [164.308 (a) (5)] - Verfahren zum Aufzeichnen der Anmeldeaktivität einschließlich fehlgeschlagener Anmeldeversuche

Gemäß diesem Verfahren müssen Sie Anmeldungen und Abmeldungen aufzeichnen, die in Ihren Systemen auftreten. Sie müssen fehlgeschlagene Anmeldeversuche verfolgen, einschließlich solcher mit einem falschen Kennwort und solcher mit einem nicht vorhandenen Konto. Die Protokollierung sollte eine fehlgeschlagene IP-Adresse, einen Anmeldenamen, einen Fehlertyp und einen Systemnamen enthalten.

Hoffe das ist nützlich ...

0
Sayan