it-swarm-eu.dev

Ist es üblich, abgelehnte Passwörter zu protokollieren?

Die Auswahl eindeutiger Passwörter für jeden Zweck ist zwar eine gute Idee, in der Praxis kommt dies jedoch selten vor. Daher wählen viele Passwörter aus einem persönlichen Pool von Passwörtern aus, die leicht zu merken sind. Bei der Authentifizierung bei Systemen, die nur selten verwendet werden, ist es sehr wahrscheinlich, dass eine Reihe von Kennwörtern aus einem solchen Pool nacheinander versucht werden. Alternativ sind fehlgeschlagene Passwörter im Falle eines Tippfehlers dem tatsächlichen Passwort sehr nahe.

Da fast niemand die geltende Kennwortrichtlinie beschreibt, einschließlich des Umgangs mit abgelehnten Kennwörtern, sollte man davon ausgehen, dass diese in einer Datenbank gesammelt werden, die an den Höchstbietenden verkauft wird?

Gibt es eine Implementierungsanleitung? Was passiert normalerweise mit einem Kandidatenkennwort, wenn dieses abgelehnt wird? Werden sie protokolliert, sofort verworfen oder bleiben, bis der Müll gesammelt ist? Sind fehlgeschlagene Kennwortbehandlungsverfahren Teil geprüfter Kontrollen? Es scheint, dass es viele Implementierungsanforderungen und Empfehlungen gibt, wie gültige Passwörter behandelt werden sollen, aber vage in Bezug auf abgelehnte Passwortwerte.

[~ # ~] edit [~ # ~]

Ich werde versuchen, hier die verschiedenen Implementierungen aufzulisten, die fehlgeschlagene Anmelde-Sicherheitsanmeldeinformationen protokollieren, um ein Gefühl dafür zu bekommen, wie weit verbreitet dieses Verfahren ist:

Content Management Systeme :

Joomla über Login Failed Log Plugin

Dieses kleine Plug-In sammelt Protokolle über jeden fehlgeschlagenen Anmeldeversuch des Administrators Ihrer Joomla-Site und sendet eine E-Mail mit dem Benutzernamen, dem Kennwort, der IP-Adresse und dem Fehler an den Superadministrator der Site.

KPlaylist v1.3 und v1.4 - ein kostenloses PHP System, das Ihre Musiksammlung über das Internet verfügbar.

protokolliert die Benutzernamen und Kennwörter fehlgeschlagener Anmeldeversuche im Apache-Fehlerprotokoll

Drupal 5.x vor Version 5.19 und Drupal 6.x vor Version 6.1 .

Wenn sich ein anonymer Benutzer aufgrund einer falschen Eingabe seines Benutzernamens oder Passworts nicht anmeldet und die Seite, auf der er sich befindet, eine sortierbare Tabelle enthält, sind der (falsche) Benutzername und das Passwort in den Links in der Tabelle enthalten. Wenn der Benutzer diese Links besucht, kann das Kennwort über den HTTP-Referrer an externe Sites weitergegeben werden.

Standalone-Software

Reporting Server, der in Symantec Client Security 3.1 und SAV CE 10.1 enthalten ist

Das Administratorkennwort für Symantec Reporting Server kann nach einem fehlgeschlagenen Anmeldeversuch bekannt gegeben werden.

Linux :

OpenSSH über modifiziertes auth-passwd.c ; Verwenden von PAM durch Überladen der Funktion pam_sm_authenticate

EDIT # 2

Es scheint ein Konsens zu bestehen, und das Aufzeichnen der fehlgeschlagenen Passwörter oder PINS wird als ernstes/schwerwiegendes Sicherheitsrisiko angesehen. Soweit ich weiß, bieten die folgenden Standards jedoch keine Leitlinien, geprüften Verfahren oder Kontrollen, die sich speziell mit diesem Risiko befassen:

  • PCI-DSS : In 8.4 beschriebene Kennwortverfahren. und 8.5. (Fehlgeschlagene Passwörter werden nur während der Übertragung geschützt; nach der Validierung werden sie nicht als Passwörter betrachtet und müssen daher nicht geschützt werden.)

  • FIPS140-2 : Authentifizierung in 4.3 adressiert (Lebenszyklus fehlgeschlagener Authentifizierungsdaten nur teilweise adressiert)

61
Drew Lex

Das Protokollieren des Werts eines fehlgeschlagenen Kennwortversuchs (Klartext oder auf andere Weise) scheint ein Sicherheits-Anti-Pattern zu sein. Ich habe noch nie eine Web-App gesehen, die dies tut, und mir sind auch keine Standardsystemdienste wie SSH bekannt, die dies tun. Wie von @tylerl unten ausgeführt, protokollieren die meisten Systeme einfach Metainformationen über einen Zugriffsversuch (z. B. Benutzername, Uhrzeit, möglicherweise IP-Adresse usw.).

Warum dies ein Sicherheits-Anti-Muster sein sollte

Nebenbei kann ich mir drei Gründe vorstellen, warum das Protokollieren des Werts eines fehlgeschlagenen Kennwortversuchs eine schlechte Idee ist:

1. Benutzertipps

Es kommt sehr häufig vor, dass Benutzer ein Kennwort mit ein oder zwei Zeichen falsch eingeben. Wenn Sie eine Protokolldatei mit fehlgeschlagenen Versuchen untersuchen, können Sie viele dieser Versuche leicht herausfinden, insbesondere wenn Sie eine Folge fehlgeschlagener Versuche einer erfolgreichen Authentifizierung gegenüberstellen könnten.

2. Guess-and-Check

Viele Menschen haben zwei oder drei Passwörter, die sie für alles durchlaufen. Folglich vergessen wann sie, welches Passwort sie auf einer bestimmten Site verwendet haben, sie durchlaufen einfach alle, bis sie eine Übereinstimmung finden. Dies würde es trivial machen, ihre Konten auf anderen Websites zu hacken.

. Log Bloat

Das Speichern fehlgeschlagener Kennwörter hat für die überwiegende Mehrheit der heute in der Produktion befindlichen Authentifizierungsdienste keinen nützlichen Zweck. Während es einige Edge-Fälle geben kann, wirft das Speichern dieser Daten für die meisten Menschen einfach Speicherplatz weg.

Zu relevanten Gesetzen/Standards

Ich kenne keine Standards (PCI, HIPAA usw.), die sich speziell mit Verfahren zum Speichern fehlgeschlagener Anmeldeversuche befassen, aber ich denke, dass angesichts der oben genannten Fakten ein gutes rechtliches Argument dafür angeführt werden könnte, warum dieselben Standards für das Speichern gelten Passwörter sollten im Allgemeinen auch für Versuche mit fehlgeschlagenen Passwörtern gelten. Mit anderen Worten, Sie könnten ein rechtliches Argument dafür vorbringen, dass ein fehlgeschlagenes Passwort immer noch kategorisch ein Passwort ist und als solches denselben Standards unterliegt.

Obwohl ich sicherlich kein Anwalt bin, möchte ich nicht, dass ein Richter entscheiden muss, ob ich fahrlässig bin oder gegen Industriestandards verstoße, da fehlgeschlagene Passwörter im Klartext gespeichert wurden und die Verbraucher unter den Folgen litten. Ich denke nicht, dass das mit einer günstigen Entscheidung enden würde.

Ich stimme dem OP zu, dass es für die verschiedenen Normungsgremien nützlich sein könnte, sich speziell mit diesem Thema zu befassen (sofern dies noch nicht geschehen ist). Zu diesem Zweck würde ich vorschlagen, einen Konformitätsstandard zu erstellen, bei dem der Wert fehlgeschlagener Kennwortversuche überhaupt nicht gespeichert wird.

68
Mark

Es gibt keinen legitimen Zweck, Klartextkennwörter für eine Anwendung zu protokollieren. vor allem für eine falsche Anmeldung. Es kann zufällig protokolliert werden - ich habe beiläufig auth.log für andere Zwecke und wenn ein Benutzer versehentlich sein Kennwort in das Anmeldefeld eingibt (und ich zeichne die Anmeldefelder auf, um zu sehen, welche Konten versucht werden, sich anzumelden) - habe ich den Benutzer jedoch darüber informiert und sie haben ihr Kennwort geändert Passwort.

Auf der anderen Seite lautet die konservative Annahme als Benutzer, dass jede zufällige Anwendung, die Sie verwenden, jedes Kennwort falscher Versuche protokolliert. Aus diesem Grund ist es eine schlechte Idee, kleine (drei) zufällige Kennwörter zu verwenden, die Sie durchlaufen, im Vergleich zu einem eindeutigen Kennwort für jede Site, die in einer verschlüsselten Kennwortliste verwaltet wird (möglicherweise mit einem Tool wie keepass).

In diesem Sinne wurde Mark Zuckerberg (Facebook-Gründer) von businessinsider.com beschuldigt, Protokolle von Login/Passwort-Kombinationen (auch aus falschen Einträgen) von thefacebook.com (eine frühe Version von Facebook), um sich in die E-Mail-Konten von Harvard Crimson-Journalisten zu hacken, die ihn untersuchten. Aus der täglichen Mail : :

Nachdem jedoch weitere Behauptungen aufgetaucht waren, wurde Zuckerberg offenbar besorgt, dass die Zeitung doch eine Geschichte über ihn erzählen würde.

Business Insider behauptete, er habe dann einem Freund erzählt, wie er sich in die Konten von Crimson-Mitarbeitern gehackt habe.

Er erzählte dem Freund angeblich, dass er TheFacebook.com benutzt habe, um nach Mitgliedern zu suchen, die sagten, sie seien hochrote Mitarbeiter.

Dann untersuchte er angeblich einen Bericht über fehlgeschlagene Anmeldungen, um festzustellen, ob eines der Crimson-Mitglieder jemals ein falsches Passwort in TheFacebook.com eingegeben hatte.

Auch etwas relevant xkcd (stellen Sie sich vor, dass die bösen Accounts auch versuchte Passwörter protokollierten, um ihre Erfolgsrate zu erhöhen).

17
dr jimbob

Es gibt oben einige großartige Antworten, daher ist dies nur eine schnelle und vereinfachte Perspektive der US-Regierungspolitik zur Verwaltung von Computersystemen, die Verschlusssachen verarbeiten.

(1) Das gesamte Computersystem muss nach dem höchsten Standard geschützt sein, der von alle Daten auf diesem Computer gefordert wird. Dies schließt Protokolle ein, die auf oder neben dem Computer gespeichert sind.

Wenn Sie beispielsweise absichtlich oder versehentlich "geheime" Daten auf einen Computer übertragen, muss JEDER Teil dieses Computers jetzt als "geheime" Informationen geschützt werden. Dies ist auch dann der Fall, wenn Sie einen nicht klassifizierten Computer hatten (wie zum Beispiel zu Hause), der eine E-Mail mit Verschlusssachen erhalten hat. Der gesamte Computer und alles darauf wird jetzt als "geheim" eingestuft.

(2) Die Passwörter für diesen Computer werden auch als die höchste Schutzstufe eingestuft, die für Daten auf diesem Computer erforderlich ist.

Wenn Sie beispielsweise "geheime" Daten auf diesem Computer haben, erfordert das Speichern des Kennworts dieselbe Schutzstufe.

Unabhängig von dem Standard, den Sie anwenden, wie z. B. PCI-DSS, NISPOM usw., können Sie keine Passwörter im Klartext in den Protokollen haben, wenn die Anforderung besteht, dass sie geschützt sind (z. B. Hash und Salted). .

Wenn also ein Regelungsschema auf Ihr fragliches Computersystem angewendet wird und diese Regelung besagt, dass Sie keine Klartextkennwörter haben können, können Sie keine Klartextkennwörter in Ihren Protokollen haben.

6
OnTheShelf

Es ist nicht ungewöhnlich, dass protokolliert wird, dass ein Authentifizierungsversuch fehlgeschlagen ist und für welchen Benutzer er bestimmt war. Dies kann sich bei der forensischen Fehlerbehebung als sehr nützlich erweisen. Aus Sicherheitsgründen ist es äußerst ungewöhnlich und unverantwortlich zu protokollieren, welches Kennwort abgelehnt wurde. Diese Informationen dienen keinem nützlichen Zweck und können gegen Sie verwendet werden.

EDIT
Sie sollten hoffentlich erwarten können, dass ein seriöses und gut organisiertes Unternehmen Ihre Passwortinformationen nicht verkauft, da dies wirklich der Fall ist schlecht für sie, wenn es herausgefunden wurde. Im Interesse Ihrer eigenen Sicherheit sollten Sie jedoch immer darauf vorbereitet sein, dass Informationen, die Sie herausgeben, gegen Sie verwendet werden, da dies immer möglich ist. Dies gilt doppelt für jede Organisation, deren Ruf Sie nicht zuverlässig etablieren können.

6
tylerl

Nein. Es ist üblich, dass Benutzer über einen Pool von Kennwörtern verfügen und diese durchlaufen, um herauszufinden, welches für eine bestimmte Site verwendet wird. Protokollierung bedeutet nur, dass wenn Sie kompromittiert werden, ihre Alternativen zum Cracker-Pool derjenigen hinzugefügt werden, die Sie geschlagen haben.

2
John Haugeland