Frage:
Ist es üblich, abgelehnte Passwörter zu protokollieren?
Drew Lex
2012-07-05 03:59:39 UTC
view on stackexchange narkive permalink

Während die Auswahl eindeutiger Kennwörter für jeden Zweck eine gute Idee ist, geschieht dies in der Praxis selten. 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 dazu sind fehlgeschlagene Kennwörter im Falle eines Tippfehlers sehr nahe am tatsächlichen Kennwort.

Da fast niemand die geltende Kennwortrichtlinie beschreibt, einschließlich des Umgangs mit abgelehnten Kennwörtern, sollte man davon ausgehen, dass diese erfasst werden Eine Datenbank, die an den Meistbietenden 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, an den Superadministrator der Site. IP-Adresse und Fehler.

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

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.13.

Wenn sich ein anonymer Benutzer nicht anmeldet Da er seinen Benutzernamen oder sein Passwort falsch eingegeben hat 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, wird das Kennwort möglicherweise über den HTTP-Referrer an externe Sites weitergegeben.

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 offengelegt werden nach einem fehlgeschlagenen Anmeldeversuch.

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 Kennwörter oder PINS wird dennoch als ernstes / großes Sicherheitsrisiko angesehen Soweit ich weiß, enthalten die folgenden Standards keine Leitlinien, geprüften Verfahren oder Kontrollen, die speziell auf dieses Risiko eingehen:

  • PCI-DSS: Kennwortverfahren, auf die in Bezug genommen wird 8.4. 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 adressiert in 4.3 (Lebenszyklus fehlgeschlagener Authentifizierungsdaten nur teilweise adressiert)

    • Verwandte Themen (zu einem bestimmten Fall, wobei diese Frage allgemeiner ist): [Sollten Kennwörter in einer Fehlermeldung angezeigt werden?] (Http://security.stackexchange.com/q/15452)
    Der Benutzer sollte verzögert und protokolliert werden, jedoch nicht mit einem Klartext-Passwort. Sie müssen einen Benutzer in einem separaten Thread oder Kontext haben, um dies zu tun, da dies in einigen Fällen andere Benutzer einfrieren kann.
    Siehe auch: http://security.stackexchange.com/questions/8323/is-it-legal-to-log-passwords-from-failed-logins
    @AndrewSmith "_Sie müssen einen Benutzer in einem separaten Thread oder Kontext haben, um dies zu tun_" Können Sie erklären, was Sie unter "Kontext" verstehen?
    Ich habe in mehreren Fällen Trojaner-Binärdateien "ssh" und "sshd" auf verwurzelten Servern gesehen, die geändert wurden, um (zusammen mit der Installation eines "Hintertür" -Kennworts) erfolgreiche Kennwörter in einer irgendwo versteckten Datei zu protokollieren. Ich stelle mir vor, es ist Teil eines Kits, da ich überall den gleichen Code sehe. Dies unterstreicht nur die Wichtigkeit der Verwendung von SSH-Schlüsseln.
    @tylerl "_Was unterstreicht nur die Wichtigkeit der Verwendung von SSH-Schlüsseln_" Könnte ein "trojanischer` ssh` "Ihren privaten SSH-Schlüssel nicht verlieren?
    @curiousguy Ihr Schlüssel sollte sicher auf Ihrem eigenen Computer und nicht auf Ihrem Server gespeichert sein.
    @tylerl Ich sehe: Der Server ist kompromittiert, nicht der Computer, von dem aus Sie "ssh" (und Sie verwenden nicht den "ssh" -Client auf dem Server). Auf jeden Fall benötigt der "sshd" nicht Ihr Passwort, um auf alle Ihre Dateien auf dem Server zuzugreifen.
    @curiousguy Die Implikation ist, dass, da es häufig vorkommt, dass dasselbe Kennwort auf mehreren Servern verwendet wird (nicht sinnvoll, aber dennoch üblich), wenn der sshd diese Kennwörter sammelt, diese nützlich sein können, um den Angriff zu verbreiten. Die Verwendung von SSH-Tasten minimiert Ihre Belichtung. Der SSH-Client auf dem Server wird aus demselben Grund trojanisiert, weshalb es nicht ratsam ist, SSH * von * einem verdächtigen Server (oder einem beliebigen Server, wenn dies vermieden werden kann) zu verwenden. Die Exposition kann durch die Verwendung eines Schlüsselagenten weiter eingeschränkt werden, dies ist jedoch mit eigenen Expositionen verbunden.
    Fünf antworten:
    Mark
    2012-07-05 05:19:51 UTC
    view on stackexchange narkive permalink

    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-Pattern sein sollte

    Ich kann mir drei Gründe vorstellen, warum das Protokollieren des Werts eines fehlgeschlagenen Kennwortversuchs schlecht ist Idee:

    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 viele davon leicht herausgefunden werden, 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. Wenn sie also vergessen, welches Passwort sie auf einer bestimmten Site verwendet haben, durchlaufen sie einfach alle, bis sie eine Übereinstimmung finden. Dies würde es trivial machen, ihre Konten auf anderen Websites zu hacken.

    3. 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 Randfä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 das sind Das Speichern von Passwörtern sollte 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 war oder gegen Industriestandards verstößt, weil fehlgeschlagene Passwörter im Klartext gespeichert wurden und die Verbraucher darunter litten Folgen. 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, dieses Problem speziell anzusprechen (sofern dies noch nicht geschehen ist). Zu diesem Zweck würde ich vorschlagen, einen Compliance-Standard zu erstellen, bei dem der Wert fehlgeschlagener Kennwortversuche überhaupt nicht gespeichert wird.

    Ich glaube, dass Sie unter HIPAA einen Audit-Datensatz für fehlgeschlagene Anmeldeversuche (ohne Kennwortinformationen) erstellen müssen, aber sie sagen nichts über die Protokollierung aus. Wenn es nicht in HIPAA ist, erfordern es Implementierungsframeworks wie IHE.
    @Oleksi guter Punkt. Ich habe meine Antwort aktualisiert, um anzugeben, dass ich den Wert eines Zugriffsversuchs speichern wollte. Jede Software in der Gesundheitsbranche sollte ein Protokoll über erfolgreiche und fehlgeschlagene Zugriffsversuche im Rahmen der HIPAA / Auditing Controls für sinnvolle Verwendung führen. Natürlich sollte dieses Protokoll keine Kennwortwerte enthalten.
    gemäß dem von [@dr jimbob unten vorgeschlagenen [Artikel:] (http://www.dailymail.co.uk/news/article-1255888/Facebook-founder-Mark-Zuckerberg-hacked-emails-rivals-journalists.html) ] (http://security.stackexchange.com/a/16839/10923) sammelte Facebook bereits 2004 den Wert fehlgeschlagener Kennwortversuche. Es gibt nichts in Bezug auf die Gesetzgebung, von dem ich weiß, dass dies erforderlich sein könnte entfernen Sie solche Praxis.
    @DrewLex - Facebook ist ein perfektes Beispiel dafür, was NICHT zu tun ist, wenn es um Sicherheit und Datenschutz geht.
    @Drew Lex - Während Facebook immer noch häufige Sicherheitslücken / Datenschutzverletzungen aufweist, bezweifle ich, dass sie falsche Passwortversuche mehr protokollieren (und die Anschuldigung des Geschäftsinhabers von einem anonymen "Freund", dass Z damit prahlte, ist kein Beweis dafür, dass dies tatsächlich passiert ist - Menschen lügen). Es scheint wahrscheinlicher, dass ein College-Kind, das alleine handelt, so etwas tut (warum nicht Protokollinformationen nützlich / cool sein könnten), als ein milliardenschweres multinationales Unternehmen mit echten Fachleuten, die sich Sorgen machen, Dinge zu tun, die nur hilfreich sein könnten illegale Dinge tun.
    PCI definiert "Passwort" wie folgt:> Eine Zeichenfolge, die als Authentifikator des Benutzers dient.
    Kevin Mitnick machte einen Hack und hatte einen Logger auf einem Remote-Server. Ein unerfahrener Systemadministrator konnte sich das Kennwort für den Server nicht genau merken. Daher durchsuchte der Systemadministrator seine Kennwörter (allesamt Netzwerkkennwörter), was Kevins Arbeit erleichtert, da er keine Kennwörter mehr hacken / knacken musste. Wenn Sie einem Programm erlauben, fehlgeschlagene Passwörter aufzuzeichnen, tun Sie fast dasselbe
    Mein Chef wollte zunächst, dass ich einen SHA256 des fehlgeschlagenen Passworts in der Tabelle sperre, und ich konnte ihn davon überzeugen.Ich denke jedoch, dass es nützlich sein könnte, einen bcrypt-Hash + Salt des letzten fehlgeschlagenen Kennworts zu speichern und damit festzustellen, ob dasselbe falsche Kennwort erneut versucht wird (wir haben einen IoT-Anwendungsfall, in dem Geräte möglicherweise automatisch versuchen, sich anzumeldendas falsche Passwort)
    dr jimbob
    2012-07-05 10:03:03 UTC
    view on stackexchange narkive permalink

    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 gelegentlich auth.log für andere Zwecke angesehen und festgestellt, dass ein Benutzer versehentlich sein Kennwort in das Anmeldefeld eingegeben hat (und ich zeichne die Anmeldefelder auf, um sie anzuzeigen Welche Konten versucht werden, angemeldet zu werden?) - Ich habe den Benutzer jedoch darüber informiert und er hat sein Kennwort geändert.

    Auf der anderen Seite wird als Benutzer konservativ davon ausgegangen, dass jede zufällige Anwendung Sie verwenden, um jedes Passwort von falschen Versuchen zu protokollieren. Aus diesem Grund ist es eine schlechte Idee, ein kleines (drei) zufälliges Kennwort zu verwenden, das Sie durchlaufen, im Vergleich zu einem eindeutigen Kennwort für jede Site, die in einer verschlüsselten Kennwortliste verwaltet wird (möglicherweise mithilfe eines Tools wie keepass).

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

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

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

    Er sagte dem Freund angeblich, er habe TheFacebook.com verwendet, um nach Mitgliedern zu suchen, die sagten, sie seien Crimson-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, die bösen Konten haben auch versuchte Passwörter protokolliert, um ihre Erfolgsrate zu erhöhen).

    +1 nur die XKCD zu erwähnen würde ausreichen, um alles zu erklären
    @dr jimbob - Re "Es gibt keinen legitimen Zweck, Klartextkennwörter für eine Anwendung zu protokollieren" - wie wäre es, festzustellen, ob ein Benutzerkonto mit brutaler Gewalt angegriffen wird?
    @Drew Lex - Sie können (und sollten) protokollieren, dass jemand von der IP-Adresse aus ein falsches Kennwort für ein Benutzerkonto eingegeben hat, und möglicherweise zusätzliche Sicherheit aktivieren (CAPTCHAs erfordern, Verzögerungen zwischen Wiederholungsversuchen, IP-Adresse sperren, Konto sperren, usw.) wenn die fehlgeschlagenen Anmeldungen zu häufig sind (z. B. ab ca. 5 aufeinander folgenden Versuchen). Es gibt jedoch keinen legitimen Grund, die Passwörter zu protokollieren, die sie tatsächlich eingeben.
    +1 für XKCD, es enthält alle notwendigen Informationen;)
    @drjimbob, Ich hatte diese Idee, zu der ich eine Frage gestellt habe. Kann dies Ihrer Meinung nach ein Punkt sein? danke http://security.stackexchange.com/questions/66484/temporically-save-failed-logins-password-hashes-for-using-against-brute-force-att
    tylerl
    2012-07-05 08:22:21 UTC
    view on stackexchange narkive permalink

    Es ist nicht ungewöhnlich, zu protokollieren, 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.

    BEARBEITEN
    Sie sollten hoffentlich in der Lage sein, dies als seriös und gut zu erwarten -organisiertes Unternehmen würde Ihre Passwortinformationen nicht verkaufen, da dies für sie wirklich schlecht wäre, wenn es herausgefunden würde. 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.

    +1 Ich habe meine Antwort angepasst, um zu verdeutlichen, dass ich den Klartextwert eines Kennwortversuchs protokollieren wollte. Ich habe auch mit einem Verweis auf Ihre Antwort aktualisiert, welche Metainformationen für Prüfungs- / Protokollierungszwecke wertvoll sind.
    OnTheShelf
    2012-07-11 00:17:13 UTC
    view on stackexchange narkive permalink

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

    (1) Das gesamte Computersystem muss geschützt werden auf den höchsten Standard, der von allen Daten auf diesem Computer gefordert wird. Dies schließt Protokolle ein, die auf dem Computer oder außerhalb des Computers gespeichert sind.

    Wenn Sie beispielsweise absichtlich oder versehentlich "geheime" Daten auf einen Computer übertragen, muss JEDER Teil dieses Computers jetzt geschützt werden als "geheime" Information. 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, was sich darauf befindet, wird jetzt als "geheim" eingestuft.

    (2) Die Kennwörter für diesen Computer werden ebenfalls mit der höchsten Schutzstufe klassifiziert, die für Daten erforderlich ist auf diesem Computer.

    Wenn Sie beispielsweise "geheime" Daten auf diesem Computer haben, wo immer Sie das Kennwort speichern, ist dieselbe Schutzstufe erforderlich.

    Wie angewendet auf Ihre Frage, unabhängig von dem Standard, den Sie anwenden, wie z. B. PCI-DSS, NISPOM usw., können Sie keine Kennwörter im Klartext in den Protokollen haben, wenn die Anforderung besteht, dass sie geschützt sind (z. B. gehasht und gesalzen).

    Wenn also ein Regulierungsschema auf Ihr fragliches Computersystem angewendet wird und diese Verordnung besagt, dass Sie keine Klartextkennwörter haben können, können Sie keine Klartextkennwörter in haben Ihre Protokolle.

    Ich bin damit einverstanden, dass jede über das Passwortfeld eingegebene Zeichenfolge als "Benutzerdaten" oder "Passwortdaten" betrachtet werden sollte, unabhängig davon, ob sich dies als gültig herausstellt oder nicht. Leider ist "Kennwort" als die Zeichenfolge definiert, die validiert wird. Dies bedeutet, dass Werte, die diese Kriterien nicht erfüllen, nicht als Kennwörter betrachtet werden. Kein Standard definiert diese umfassendere Definition eines "Passworts". [SP800-53] (http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf) sagt nichts über fehlgeschlagene Kennwortwerte aus.
    Alle Informationen, die ein Benutzer als Sicherheitstoken geltend macht, werden von jeder zuständigen Regulierungsbehörde als Passwort behandelt, auch wenn sie falsch geschrieben sind. Ein Sicherheitsmanager, der das Argument verwendet, dass ein vom Benutzer angegebenes Kennwort, das den Benutzer nicht authentifiziert, keinen Schutz auf Systemebene benötigt, sollte aufgrund von Fehlverhalten von seiner Position entfernt werden. In den meisten regulierten Umgebungen würde ich auch erwarten, dass sie von der zukünftigen Arbeit in regulierten Sicherheitsprogrammen ausgeschlossen werden. Noch wichtiger wäre, dass sie unglaublich amateurhaft aussehen würden.
    John Haugeland
    2012-07-06 05:38:32 UTC
    view on stackexchange narkive permalink

    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, deren Alternativen zum Cracker-Pool desjenigen hinzugefügt werden, der Sie geschlagen hat.



    ⓘ
    Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
    Loading...