Frage:
Gibt es einen Grund, Benutzern nach einer erfolgreichen Anmeldung keine falsch eingegebenen Passwörter anzuzeigen?
RaunakS
2016-09-09 23:35:54 UTC
view on stackexchange narkive permalink

Unser Client hat die Anforderung aufgestellt, dass für den Fall, dass der betreffende Benutzername mehrere fehlgeschlagene Anmeldeversuche hatte, die falsch eingegebenen Kennwörter angezeigt werden müssen, sobald eine erfolgreiche Anmeldung durchgeführt wurde. Richtig eingegebene Informationen, einschließlich vorheriger Passwörter, werden auf keinen Fall angezeigt.

Unsere leitende Entwicklerin hat uns mitgeteilt, dass dies technisch möglich ist, indem sie keine falschen Eingaben hasht, aber sie ist äußerst unangenehm mit der Funktion und daher wurde sie angehalten, während wir ein Brainstorming durchführen.

Bei der fraglichen Website handelt es sich um eine umfassende Mapping- / GIS-Anwendung, die keine Geldtransaktionen enthält was auch immer. Weitere Anmelde- / Authentifizierungsoptionen sind Google / LinkedIn / Twitter / Facebook. Daher müssen dort offensichtlich keine Kennwörter gespeichert werden. Dies ist in erster Linie ein UX-Problem.

Welche Sicherheitslücken treten bei der Implementierung einer solchen Funktion auf? Unser Kunde ist nicht ganz ohne technisches Wissen, daher reicht eine allgemeine Erklärung aus.

Ich entschuldige mich, wenn die Frage zu weit gefasst oder die Antwort sehr offensichtlich ist.

Fragen Sie den Kunden warum.Dann fragen Sie, warum über was auch immer sie sagen.Sie haben vielleicht eine Idee, aber sie wollen das sicherlich nicht.
enorme rechtliche Haftung - nicht umsetzen, es sei denn, Sie lassen den Kunden alle rechtlichen Verpflichtungen Ihres Unternehmens aufheben
Was @timpone sagt.Weil, wie jeder in infosec genau weiß, Menschen oft 100 Konten haben (ich habe 154) und sich kein Mensch an all das erinnern kann, geschieht die Wiederverwendung.Selbst wenn Ihre Site wenig zu verlieren hat und selbst wenn der Benutzer sein Passwort mit anderen Sites teilt, die wenig zu verlieren haben (z. B. FooFlix, was wird er tun, einige Filme stereamieren?), Stellen Sie sich seine Überraschung vor, wenn ein Hacker * einen Weg findet * (zB Tausende von Dollar an Geschenkmitgliedschaften kaufen).
(Überzeugen Sie Ihren Kunden und) gehen Sie einfach mit den Standard-Bildschirmschoner-Informationen: * "Die Anmeldeversuche waren X nicht erfolgreich" *.
Zeigen Sie ihnen ein SSH-Protokoll von einem öffentlichen Server und zeigen Sie, wie kontinuierlich fehlgeschlagene Anmeldungen aus der ganzen Welt protokolliert werden.Der wahrscheinlichste Inhalt dieses Protokolls sind 100 MB Versuche mit "Passwort", "1234" usw. - nicht nützlich, damit jemand * jedes Login * sieht.Wenn Sie das Protokoll nach einer erfolgreichen Anmeldung löschen, wird jemand nie erfahren, ob sich jemand anders als er angemeldet hat, nachdem er einige Male das Passwort erraten hat.Wenn Sie dies nicht tun, sehen Sie für immer frühere Tippfehler, die Sie kennen und die Sie nicht interessieren.Und wenn Sie zwei fehlgeschlagene Anmeldungen sehen, was nützt das überhaupt?Wer profitiert in irgendeiner Weise von dieser "Funktion"?
Tricky ... Ich für meinen Teil habe einen (großen) Satz von Passwörtern, die ich auf verschiedenen Websites verwende. Obwohl ein Kennwort auf einer Website möglicherweise falsch ist, ist es auf mehreren anderen Websites immer noch korrekt.Anschließend würde ich es vorziehen, wenn eine Site meine "falschen" Passwörter nicht zu speichern oder sie mir ** im Klartext ** zurückzusenden, damit sie von irgendjemandem gelesen werden können!
Geben Sie stattdessen eine Schaltfläche an, auf die ein Benutzer klicken kann, um das Kennwortfeld zu maskieren / zu demaskieren.Passwörter sollten nur angezeigt werden, wenn der Benutzer dies erwartet.
Die sichere Speicherung falscher Passwörter ist möglich.Die bisher gegebenen Antworten geben Ihnen jedoch bereits genügend Gründe, warum Sie dies nicht tun sollten.Also werde ich Ihnen den Algorithmus nicht geben.Stattdessen werde ich Ihnen sagen, dass die Passwörter den Benutzern gehören.Die Passwörter gehören nicht Ihrem Kunden.Ihr Kunde fordert Sie auf, diese Passwörter zu missbrauchen.Sie müssen sich fragen, ob Sie Ihrem Kunden wirklich helfen möchten, seine Benutzer zu missbrauchen.Was Sie wirklich brauchen, ist das bestmögliche Argument, um Ihren Kunden davon zu überzeugen, stattdessen eine geeignete Lösung zu wählen.
Möglicherweise wollte Ihr Kunde die Anzahl der falsch eingegebenen Passwörter anstelle der tatsächlich falschen Passwörter anzeigen.Das erste ist, was SAP auch tut.Letzteres ist unbekannt.
Das ist eine schreckliche Idee.Das Hashing-Problem und das Problem mit dem Benutzernamen / Passwort für gekreuzte Konten sollten diese Idee ausschließen.Ich schaue mich immer nach Antworten auf solche Probleme um und denke, wenn dies ein gutes Muster wäre, würden Orte wie Google usw. es verwenden.Weisen Sie Ihren Kunden zusammen mit allen bereits erwähnten Punkten darauf hin.Erinnern Sie die Kunden immer daran, dass das Rad selten neu erfunden werden muss.
** Bad bad bad: ** `hunter3`,` junter2`, `hunrer2` und jetzt kennst du mein Passwort.
Ich kenne eine Website, die dies tut (oder zumindest gewohnt ist).Und ich habe diese "Funktion" genutzt, um die Nutzungsbedingungen dieser Website zu umgehen und keine Kontaktinformationen mit anderen Benutzern zu teilen.
High Five an den leitenden Entwickler, der sein Unbehagen zum Ausdruck brachte und dieses Problem provozierte!
Wenn Sie messen könnten, wie unterschiedlich es vom ursprünglichen Passwort ist, könnten Sie Tippfehler anzeigen, aber dann müssten Sie Ihre Passwörter unversehrt speichern.
Fügen Sie einfach Zutaten zu den bereits guten Antworten hinzu. Verwenden Sie diese Website, um https://haveibeenpwned.com/ zu sehen.
Wenn ich ein Open Source-Projekt finden würde, das dies tut, würde ich ihm wahrscheinlich eine CVE-Kennung zuweisen, da dies im Allgemeinen als Sicherheitslücke angesehen wird.
Als Systemadministrator ist es nützlich, fehlgeschlagene Versuche auf irgendeine Weise zu charakterisieren, um zwischen einem Benutzer, der versucht, sich sein eigenes Passwort zu merken und es einzugeben, und einer Art Angriff zu unterscheiden.Wenn erstere, bieten Sie dem Benutzer Hilfe an.Wenn letzteres der Fall ist, starten Sie Abwehrmaßnahmen.
Ihr leitender Entwickler ist schlau, lassen Sie sie nicht los
Zwei Wörter: Umsetzungsfehler.
Wenn ich auf ein System stoßen würde, das mir meine falsch eingegebenen Klartext-Passwörter präsentiert, würde ich mein Konto schließen und dieses System nicht mehr verwenden und Freunden und Familienmitgliedern empfehlen, diesen Dienst zu meiden.Es ist praktisch garantiert, dass wenn ich mein Passwort falsch eingegeben habe, es entweder um ein Zeichen deaktiviert ist oder ich eines meiner Passwörter von einem anderen Konto aus eingegeben habe.In jedem Fall ist es für jedes Unternehmen fahrlässig, eine Liste meiner falsch eingegebenen Passwörter zu führen.Dies ist nur eine unglaublich schlechte Idee.
Dreizehn antworten:
PwdRsch
2016-09-10 00:08:45 UTC
view on stackexchange narkive permalink

Das Hauptproblem besteht darin, dass falsche Passwörter so gespeichert werden müssen, dass sie später den Benutzern angezeigt werden können. Was, wie Ihr Entwickler betonte, bedeutet, dass sie nicht zuerst kryptografisch gehasht werden können. Das Ergebnis ist, dass Sie sie entweder als Klartext (schlecht) oder verschlüsselt (besser, aber normalerweise nicht empfohlen) speichern.

Das größte Risiko besteht darin, dass Angreifer auf diese Datenbank mit ungültigen Kennwörtern zugreifen können. Entweder gefährden sie den Server, führen eine SQL-Injection durch oder rufen ihn auf andere Weise ab. Anstatt die primären Kennwörter zu knacken, die hoffentlich stark gehasht und daher härter sind, könnten sie beschließen, Konten mithilfe der Informationen im ungültigen Kennwortverlauf zu kompromittieren. Entweder greifen sie einfach auf die Klartextkennwörter zu, oder sie versuchen, den Verschlüsselungsschlüssel zu finden, mit dem sie wieder in Klartextkennwörter entschlüsseln können.

Eine häufige Ursache für Anmeldefehler sind geringfügige Tippfehler während der Kennworteingabe. Mein Passwort ist also Muffins16, aber ich gebe mUFFINS16 ein, weil meine Feststelltaste aktiviert ist. Oder Muffins166, weil ich zweimal dieselbe Taste gedrückt habe. Oder Muffina16, weil mein Finger die falsche Taste gedrückt hat. Wie Sie sehen können, sind diese Variationen nahe genug am Original, sodass Angreifer das gültige Kennwort wahrscheinlich aus ungültigen Kennwörtern ermitteln können, indem sie einige geringfügige Änderungen vornehmen oder falsche Kennwörter mit wahrscheinlichen Wörter oder Wörtern aus dem Wörterbuch vergleichen.

Dieses Problem ist verschärft, weil die meisten Leute Passwortwahlen ähnlich diesen Formaten und keine zufälligen Zeichenfolgen verwenden. Für einen Angreifer ist es schwieriger, den Tippfehler zu identifizieren, wenn Ihr ungültiges Passwort V8Az $ p4 / fA lautet. Es ist jedoch noch viel einfacher, Variationen davon auszuprobieren, als sie ohne Informationen zu erraten.

Ein weiteres Risiko besteht darin, dass sich Benutzer möglicherweise nicht daran erinnern, welches ihrer Kennwörter sie auf dieser Website verwendet haben, sodass sie ihre gemeinsamen Kennwörter ausprobieren. Jetzt ist diese Site plötzlich ein größeres Ziel, da ein Angreifer möglicherweise nicht nur das Konto eines Benutzers dort, sondern auch auf anderen Sites mit der praktischen Liste "ungültiger" Passwörter gefährden kann.

Sie können einige davon abschwächen Risiken durch Löschen der Speicherung ungültiger Kennwörter unmittelbar nach der Anzeige nach einem gültigen Login. Dies sollte das Zeitfenster für einen Angreifer einschränken, auf die Daten zuzugreifen und von ihnen zu profitieren.

Die Frage, die Sie Ihrem Client wahrscheinlich stellen sollten, ist, wie er vorhersagt, dass Benutzer von der Anzeige ihrer ungültigen Kennwörter profitieren werden. Ist es so, dass Benutzer erkennen können, wie sie ihr Passwort falsch eingegeben haben? Tippfehler sind nicht beabsichtigt, daher ist es unwahrscheinlich, dass das Anzeigen ihres Fehlers zukünftige Anmeldeversuche verbessert. So können Benutzer einen Angreifer identifizieren, der versucht, seine Passwörter zu erraten? Ein ähnliches Feedback kann durch Auflisten von Datum, Uhrzeit, IP / Geolocation oder anderen Informationen für ungültige Versuche ohne das versuchte Passwort gegeben werden. Benutzer wissen also, dass sie es bei der Passworteingabe vermasselt haben und geben dem Anmeldesystem der Site keine Schuld? Dies scheint der einzige zu sein, der Verdienste hat, und ich bin mir nicht sicher, ob er genug Wert bietet, um das Risiko zu rechtfertigen.

Ich vermute, wenn Sie erst einmal besser verstanden haben, was sie mit dieser Funktion erreichen wollen, können Sie dies tun schlagen wahrscheinlich sicherere Alternativen vor.

Wie lautet Ihre E-Mail-Adresse, damit ich das Passwort Muffins16 darauf ausprobieren kann?Ich meine, diskutieren Sie dieses wichtige Thema weiter mit Ihnen?
Offensichtlich ist das ein Trick, das wahre Passwort * ist * mUFFINS16.
Das Knacken der Datenbank wäre * extrem * einfach - versuchen Sie einfach 1000 falsche Passwortversuche auf mehreren Dutzend Konten, bevor Sie die verschlüsselte Datenbank stehlen.Voila, Sie haben jetzt mehrere tausend "bekannte Klartext" -Passwörter in der Datenbank, aus denen Sie den Verschlüsselungsschlüssel ermitteln können.
@Wildcard ähm, was?Warum würde bekannter Klartext helfen, den Schlüssel eines modernen Krypto-Algorithmus zu knacken?
Mindestens das Root-Passwort eines Systems wurde aus der Liste der falschen Passwörter kompromittiert.
@Ben Ich denke, es geht ihm darum, die falschen Passwörter zu knacken, die in der Datenbank gespeichert sind.Angenommen, diese werden verschlüsselt gespeichert.Wenn ein Angreifer über Daten aus der Datenbank verfügt oder Zugriff darauf hat, hilft ein sehr großer Bereich bekannter Eingaben dabei, die Ausgabe umzukehren, wodurch die verwendete Verschlüsselung angezeigt wird. Dies bedeutet, dass Sie leicht auf ein falsches Kennwort zugreifen könnenin der Datenbank gespeichert.
Eine Gegenstimme reichte für diese erstaunliche Antwort nicht aus.Schätzen Sie wirklich Ihren Beitrag ..
@vlaz Der Punkt ist, dass moderne Krypto nicht anfällig für einen [bekannten Klartext-Angriff] ist (https://en.wikipedia.org/wiki/Known-plaintext_attack). Wenn Sie also eine beliebige Anzahl bekannter Klartexte haben, können Sie die verschlüsselten Passwörter nicht knacken.
Ein weiteres ziemlich großes Problem ist das Schulter-Surfen.Ich muss Ihren Server nicht knacken, wenn Sie nur auf den Bildschirm eines anderen blicken.Und wenn der CEO ein SSL-Zertifikat eingespart hat, haben Sie natürlich viel größere Probleme, sodass Sie sie genauso gut nicht noch weiter verschärfen können.
Abgesehen von der Tatsache, dass die allgemeine Idee nicht so toll ist;Könnte das hier identifizierte Hauptrisiko gemindert werden, indem falsche Kennwortversuche in einem Cookie gesammelt werden, anstatt sie dauerhaft auf der Serverseite zu speichern, oder sogar nur auf der Clientseite mit lokalem Speicher?Sie würden die Fähigkeit verlieren, fehlgeschlagene Anmeldungen von anderen Computern zu sehen ... aber es ist nicht wirklich klar, dass dies eine Anforderung aus der Beschreibung des OP ist.
Wenn angezeigt werden soll, wie Benutzer ihre Kennwörter falsch eingeben, besteht die sicherste Option darin, eine Schaltfläche bereitzustellen, mit der das Kennwort während der Eingabe angezeigt wird.Und es wäre am besten, den sichtbaren Wert nicht einzureichen.Das heißt, der Wert "
@JasonC: Das Speichern von Passwörtern in Cookies birgt leider das gleiche Risiko, da sie verwendet werden können, um Ihr Passwort aus Ihren fehlgeschlagenen Versuchen zu erraten.Auch wenn Cookies verschlüsselt sind, muss der Schlüssel irgendwo gespeichert werden.Wenn dieser Schlüssel kompromittiert wird, ist sein Spiel beendet (der Zugriff auf die Cookies ist sehr einfach, wenn Sie physischen Zugriff auf das Gerät haben, und relativ einfach, wenn Sie Code in das System einfügen können).
@lepe Dafür benötigen Sie kein Cookie.Konnte der Client diese Werte nicht lokal im Speicher speichern, wenn der Server mit einem fehlgeschlagenen Anmeldeversuch antwortet?Sobald der Server schließlich mit einem Anmelde-OK antwortet, kann der Client alle Kennwörter anzeigen, die er im Speicher hat.Nichts davon erfordert das Speichern nicht verwaschener Kennwörter auf der Serverseite oder in einem Cookie, und dies birgt kein höheres Risiko als das erstmalige Sammeln und Übermitteln der Anmeldeinformationen.
Ein weiteres Problem wäre, dass die Leute vergessen, welches Passwort sie für Ihre Anmeldung verwendet haben.Ich stelle mir vor, dass es eine beträchtliche Anzahl von Benutzern gibt, die eine Handvoll Passwörter für alle Konten verwenden.Wenn man nicht arbeitet, durchlaufen sie einfach ihre Liste, bis man arbeitet.Das Speichern der fehlgeschlagenen Versuche bedeutet das Speichern der tatsächlichen Kennwörter auf anderen Websites.
@Andonaeus: ja das ist eine möglichkeit.Mir ist immer noch unklar, was ihre Absicht hinter dieser Bitte ist.Wenn sie einen Anmeldeversuch zeigen möchten (was meiner Meinung nach der Fall sein könnte), dann ist das, was wir hier diskutieren, ein völlig anderes Tier.
Egal was Sie tun, das falsche Passwort wird vorübergehend irgendwo im Speicher gespeichert.Um dies länger zu halten, speichern Sie das Kennwort normalerweise nur in einer Sitzung, die temporär und normalerweise nur im Speicher und nicht im permanenten Speicher gespeichert ist.Was ist hier das zusätzliche Risiko, dass die fehlerhaften Passwörter länger (Minuten?) Gespeichert werden, während sich der Benutzer anmeldet?Um den Hash überhaupt ausführen zu können, muss das Passwort natürlich gespeichert sein, damit Sie sowieso nie perfekt werden.
@corsiKa Meine Kinder sagen mir, wenn das Passwort Muffins16 ist, muss die E-Mail-Adresse derpy.hooves@ponyville.eq sein
TTT
2016-09-10 00:03:16 UTC
view on stackexchange narkive permalink

tldr; Dies ist noch schlimmer, als Ihre Passwörter nicht zu hashen und als einfachen Text zu speichern.

Ich stimme den Bedenken Ihres Hauptentwicklers zu. Um frühere falsche Kennwortversuche anzuzeigen, müssen Sie diese reversibel speichern. Dies bedeutet, dass sie nicht gehasht werden können. Wenn jemand das System kompromittieren würde, hätte er Zugriff auf alle schlechten Versuche und könnte wahrscheinlich die wahren Passwörter für einige Benutzer zusammenfügen. Wenn Sie zum Beispiel sehen können, dass einige meiner schlechten Versuche waren: 

  richtige schreckliche Batterie-Heftklammerkorrekte Heftklammer für Pferdekämpfe

Es wäre ziemlich einfach herauszufinden Mein tatsächliches Passwort.

Ich stimme auch der Antwort von drawbenn zu: Wenn ich meinen Benutzernamen falsch, aber mit meinem richtigen Passwort eingebe und der falsche Benutzername jetzt zufällig der Benutzername eines anderen ist Dieser Benutzer kann mein echtes Passwort sehen.

Eine weitere Sicherheitslücke: Sobald Sie sich erfolgreich angemeldet haben, kann jeder, der auch auf Ihren Bildschirm schaut, die schlechten Versuche sehen, ohne dass er Zugriff auf die Datenbank erhalten muss.
Außerdem können Sie das richtige Passwort (Pferdebatterie-Heftklammer) nicht verwerfen, sobald es gehasht wurde.Sie müssen warten, bis nach der Überprüfung festgestellt wurde, ob es aufbewahrt oder gelöscht werden soll.
@GhillieDhu Das ist ein sehr kurzes Zeitfenster und das Passwort würde sich nur im RAM befinden.(Und das Passwort befand sich * bereits * im RAM, sodass Sie es hashen konnten. Wenn Sie es einige Millisekunden länger dort belassen, wird dies nichts Wesentliches bewirken.)
Der untere Absatz dieser Antwort ist so ziemlich das schlimmste Beispiel dafür, dass dies ** NIE ** getan werden sollte.
Sollte es nicht tsdr sagen?
user15392
2016-09-09 23:38:27 UTC
view on stackexchange narkive permalink

Einmal habe ich versucht, mich mit meinem Kennwort, aber dem Benutzernamen meines Kollegen bei einem System anzumelden.

Dann habe ich immer wieder das falsche Kennwort verwendet, als ich versucht habe, mich bei einem freigegebenen Konto anzumelden.

Und ich weiß, dass vielen Administratoren Zugriff auf das Konto ihres Chefs gewährt wird, damit sie Dinge erledigen können. Ich wäre ziemlich schockiert, wenn ihre Chefs niemals das falsche Passwort eingegeben hätten und dann von einem Besucher abgelenkt worden wären, bevor sie sich korrekt angemeldet hätten, um den Fehler zu beheben.

Plus all die Tippfehler, wenn jemand über meiner Schulter steht, während ich ' Ich melde mich an.

Und in all diesen Fällen habe ich manchmal mein Google Mail- oder Lastpass-Passwort in die Passwortabfrage bei der Arbeit eingegeben und umgekehrt.

Und die Zeit, zu der ich Ich habe mein Passwort gegoogelt, weil ich nicht auf den Bildschirm geschaut habe und nur angenommen habe, dass er gesperrt ist. Nicht, dass das irgendetwas mit Ihrem Vorschlag zu tun hat, aber ich teile diese Anekdote gerne, weil sie die Leute daran erinnert, dass jeder Fehler machen und manchmal das Falsche eingeben kann.

Die Das einzige, was diese Funktion von hUnt3r2 bewirkt, ist, kleine Fehler (Eingabe des falschen Passworts oder falsche Eingabe) in versehentliche Exposition gegenüber einem breiteren Publikum umzuwandeln.

Wenn ich Ihr Konto gezeichnet habe, muss ich nur einige gängige Typen Ihres Benutzernamens einrichten: drawben / derwbenn / ... und warten, bis Sie Ihren Benutzernamen falsch eingegeben haben, und mir Ihr Passwort senden: -o
@Falco sollten Sie das als Antwort hinzufügen.Dies ist eine gute Möglichkeit, Benutzer auf einem System wie diesem aktiv anzugreifen (und etwas, das für das Ziel unsichtbar wäre, vorausgesetzt, die übliche (und gute) Sicherheitsmaßnahme, bei der "falsches Kennwort" denselben Fehlercode wie "ungültiger Benutzer" zurückgibt).
John Wu
2016-09-10 02:39:07 UTC
view on stackexchange narkive permalink

Reputationsverlust

Die Einrichtung eines solchen Mechanismus würde zu einem sofortigen Reputationsverlust führen, wenn man bedenkt, dass es bekannte Fälle gab, in denen fehlgeschlagene Anmeldeversuche verwendet wurden, um andere Websites anzugreifen. Hier ein Beispiel:

Mark (Zuckerberg) hat auf seiner Website TheFacebook.com nach Mitgliedern der Website gesucht, die sich als Mitglieder der Crimson identifiziert haben. Dann untersuchte er ein Protokoll mit fehlgeschlagenen Anmeldungen, um festzustellen, ob eines der Crimson-Mitglieder jemals ein falsches Passwort in TheFacebook.com eingegeben hatte. Wenn die Fälle, in denen sie eingegeben hatten, fehlgeschlagen waren, versuchte Mark, sie zu verwenden, um auf die Harvard-E-Mail-Konten der Crimson-Mitglieder zuzugreifen. Er hat erfolgreich auf zwei von ihnen zugegriffen.

Mit anderen Worten, Mark scheint private Anmeldedaten von TheFacebook verwendet zu haben, um sich in die separaten E-Mail-Konten einiger TheFacebook-Benutzer zu hacken.

Quelle: Wie Mark Zuckerberg sich in das Harvard Crimson gehackt hat

Eine Alternative

Wenn Ihr Kunde unbedingt zeigen möchte, dass dies fehlgeschlagen ist Anmeldeversuche bei der nächsten erfolgreichen Anmeldung, als eine Art Wohlfühlmaßnahme, kann ich eine Alternative vorschlagen? Anstatt die fehlgeschlagenen Kennwörter anzuzeigen, zeigen Sie die IP-Adresse und die Geolokalisierungsinformationen des Browsers an, der das falsche Kennwort übermittelt hat. Sollte ziemlich einfach zu tun sein, würde kein Sicherheitsproblem verursachen und würde im Falle einer tatsächlichen böswilligen Aktivität viel nützlichere Informationen liefern.

Schöne Alternative!Es könnte erweitert werden, um auch statistische Informationen darüber enthalten, wie nah die fehlenden Passwörter dem echten waren, wie der „4% Unterschied“.So kann die Nutzerin noch besser beurteilen, was ihre eigenen gescheiterten Login-Versuche und was Hacking-Versuche waren.Schwierig zu implementieren, da wir sicher nur auf ein fehlgeschlagenes Passwort oder das echte Passwort im Klartext (beim Login vor dem Hashing) zugreifen können und sie nicht speichern können.Vielleicht möglich mit [funktionale Verschlüsselung] (https://en.wikipedia.org/wiki/Funktion_encryption)?
@tanius nein, die Seite sollte ** nicht ** in der Lage sein, diesen Unterschied zu berechnen!
Ihre erwähnte Alternative ist das, was bei Steam passiert, wenn Ihr Konto kompromittiert wurde, der Angreifer jedoch keinen Zugriff auf Ihren zweiten Autorisierungsfaktor hat.Es wird angezeigt, welches Gerät versucht, Zugriff zu erhalten, damit Sie überprüfen können, ob Sie etwas vermasselt haben oder angegriffen werden.Es funktioniert ziemlich gut und ist um einiges besser als das, was der OP-Kunde vorgeschlagen hat.
@guntbert, zu dem Zeitpunkt, an dem die falschen Passwörter * angezeigt * würden, steht das richtige Passwort zum Vergleich zur Verfügung, auch wenn es richtig gehasht wurde, da der Benutzer es gerade eingegeben hat.
@Ben Richtig, aber das Speichern der falschen Passwörter ist das Problem (kein Hashing möglich).
Warum vertrauen wir Mark mit dem Datum von Milliarden von Menschen, wenn er sich als unzuverlässige Person erwiesen hat, die aktiv versucht, Menschen zu hacken?
Joshua Hunter
2016-09-14 02:30:19 UTC
view on stackexchange narkive permalink

Ein nicht sicherheitsrelevanter Grund, dies nicht zu tun: Schlechter Anmelde-Spam.

Ich führe meine Liste mit E-Mails / Benutzernamen für Ihre Anwendung aus. Ich versuche, mich bei jedem Konto mit demselben 'Passwort' anzumelden. Vielleicht eine beleidigende Phrase; politischer Slogan oder einfach eine Anzeige für eine Website.

Dann meldet sich jeder Ihrer Benutzer an. Diejenigen mit den Benutzernamen / E-Mails, die ich vermutet habe, müssen sich alles ansehen, was ich eingegeben habe.

Es gibt jeder einzelnen anonymen Person einen Vektor zum Anzeigen von Inhalten an Ihre Benutzer.

Bei Mitarbeitern, die den Dienst nutzen und die wahrscheinlich die Anmeldenamen der anderen erraten können, kann dies sogar zu Belästigungen oder anderen HR-Problemen am Arbeitsplatz führen.

Dies ist ein sehr wichtiges Thema, das meiner Meinung nach nicht genügend Beachtung gefunden hat.
Ich hatte vorher noch nicht darüber nachgedacht, aber es ist tatsächlich ein Sicherheitsproblem.
sixtyfootersdude
2016-09-10 02:22:18 UTC
view on stackexchange narkive permalink

Was passiert, wenn ich mich bei Ihrer App anmelden möchte und mit meinem Kollegen zusammen sitze? Angenommen, ich habe mein Passwort falsch eingegeben. Muss ich ihn jetzt wegschicken, während ich mich anmelde, damit er meinen Passwortversuch nicht sieht?

"Was passiert, wenn ich mich bei Ihrer App anmelden möchte und mit meinem Kollegen zusammen sitze?"- Ich kenne jemanden, dessen gesamtes Labor sich als Doktoranden darin geschult hat, die Passwörter des anderen zu lesen, indem sie sich gegenseitig beim Tippen zuschauen.Hilft es anscheinend mehrmals zu sehen.Muss eine Minute dort unten ein Lachen gewesen sein, und wenn Sie dies tun, nehmen Sie den ganzen Spaß daraus.Sicherheitsregel Nummer eins: Sei kein Killjoy, halte es für die Angreifer herausfordernd.
webbster
2016-09-11 03:53:22 UTC
view on stackexchange narkive permalink

Wenn es Benutzer mit ähnlichen Benutzernamen / E-Mail-Adressen gibt, versuchen sie möglicherweise versehentlich, sich bei einem anderen Benutzerkonto anzumelden.

Ein böswilliger Benutzer könnte dann seine Liste mit "falschen" Kennwortversuchen verwenden, um in Konten mit ähnlichen Benutzernamen / E-Mail-Adressen (z. B. bill11, bill1 usw.) einzubrechen.

Ich denke Es ist besser, einfach schlechte und erfolgreiche Anmeldeversuche zusammen mit der Zeit und der relevanten IP-Adresse aufzulisten.

Dies scheint mir ein weitaus größeres Risiko zu sein als das akzeptierte Risiko "Was ist, wenn die DB in die falschen Hände gerät?".Es gibt eine beliebige Anzahl von Systemen, auf denen ich versuche, mich zu registrieren, meinen bevorzugten Benutzernamen zu finden und durch andere zu blättern.Nach einiger Zeit habe ich vergessen, welche ich für eine bestimmte Site verwendet habe, daher muss ich sie durchlaufen, wenn ich nach einer Abwesenheit versuche, mich anzumelden.Mein Passwort wird jedoch immer aus dem Site-Namen plus Jahr plus anderen Details berechnet und ist daher unverändert.Während die DB möglicherweise in die falschen Hände gerät, wird es Benutzer geben, die die korrekten Passwörter anderer Personen sehen.
Seth R
2016-09-10 03:17:24 UTC
view on stackexchange narkive permalink

Ich stimme anderen Antworten zu und weise darauf hin, dass es einfach ist, das Passwort eines Benutzers zu erraten, wenn ein Angreifer die Liste der fehlgeschlagenen Versuche abgerufen hat.

In diesem Fall spielt es keine Rolle, dass Ihr System keine Informationen zu Geldtransaktionen enthält. Es ist üblich, dass Benutzer an mehreren Standorten dasselbe Kennwort oder Variationen desselben Kennworts verwenden. Möglicherweise wird ihnen geraten, dies nicht zu tun, aber es passiert trotzdem. Nur weil Sie nicht der Meinung sind, dass Ihr System vertrauliche Informationen selbst preisgibt, bedeutet dies nicht, dass die vertraulichen Informationen Ihrer Benutzer nicht gefährdet werden, wenn Ihr System kompromittiert wird.

Wenn Joe User dasselbe Kennwort auf Ihrem System verwendet Wenn ein Angreifer in der Lage ist, sein Passwort auf Ihrem System zu erraten und herauszufinden, welche Bank Joe verwendet hat, kann der Angreifer auf Joes Bankkonto zugreifen. Oder Krankenakten oder ein anderes System, für das Joe dieses Kennwort verwendet hat.

Sie schützen nicht nur die Kennwörter für Ihr System.

Und wenn ich versehentlich mein streng geheimes Bankkennwort für Ihr System eingebe, wird es auch gespeichert.
Damian Yerrick
2016-09-12 04:20:09 UTC
view on stackexchange narkive permalink

Ich vermute, dass Ihr Kunde an einem XY-Problem leidet. Dies bedeutet, einen Schritt zurückzutreten und herauszufinden, was Ihr Kunde wirklich will. Oft ist es nützlich zu wissen, dass jemand ein falsches Passwort versucht hat und wie dieses Passwort eingegeben wurde, nicht unbedingt was dieses Passwort war. Möglicherweise möchte der Client nur genügend Informationen, um harmlose Bedrohungen wie das Fetten Ihres eigenen Passworts von verdächtigeren zu unterscheiden, z. B. das Erraten von Passwörtern aus der Hälfte des Landes auf einem Gerät, das sich noch nie zuvor angemeldet hat.

Fragen Sie Ihren Client nach dem Bedrohungsmodell und prüfen Sie, ob die folgenden Informationen ausreichen:

  • Benutzer-ID, für die die Authentifizierung fehlgeschlagen ist (damit Sie wissen, wen Sie bei jedem Fehler warnen müssen)
  • Datum und Uhrzeit
  • IP-Adresse des Clients, Benutzeragent und ungefähre Geolokalisierung
  • , ob auf dem Client JavaScript ausgeführt wird (Angreifer kümmern sich häufig nicht darum)
  • ob der Client ein Cookie für die erfolgreiche Anmeldung in der Vergangenheit angezeigt hat

Zeigen Sie dann ein Warnfeld basierend auf diesen Informationen an, wenn sich ein Benutzer nach einem oder mehreren Fehlern erfolgreich anmeldet.

Ein Warnfeld reicht möglicherweise nicht aus, wenn mehrere Versuche unternommen wurden.Außerdem sollte der Benutzer in der Lage sein, auf Wunsch zur Liste zurückzukehren
Der mit Abstand beste Grund, die alten Passwörter nicht zu zeigen, ist in der Tat, dass ** es nicht nötig ist **, etwas so Kniffliges zu tun.- Mein erster Gedanke, warum die Leute dies wollen, ist, dass sie nicht glauben, dass sie dicke Finger haben. In diesem Fall könnten Sie einfach so etwas wie "Einfügen drücken, um das Passwort anzuzeigen" verwenden, wie es in den wichtigsten Softwarelösungen implementiert ist.
v7d8dpo4
2016-09-10 11:44:06 UTC
view on stackexchange narkive permalink

Eine mögliche Lösung: Da es hier darum geht, falsche Kennwortversuche im Klartext zu speichern, vermeiden Sie dies. Wenn das Kennwort eines Benutzers festgelegt ist, generieren Sie ein Paar aus öffentlichem und privatem Schlüssel. Speichern Sie den öffentlichen und den privaten Schlüssel, die mit dem Kennwort verschlüsselt sind. Wenn Sie falsche Passwörter protokollieren, verschlüsseln Sie diese mit dem öffentlichen Schlüssel (und fügen Sie Salt hinzu). Auf diese Weise kann nur der Benutzer, der das richtige Passwort kennt, die falschen Passwörter sehen.

Dies scheint eine praktikable Lösung für das Hauptproblem zu sein.Aufgrund der versehentlichen Anmeldung mit Ihrem Benutzernamen wird das Kennwort anderer Personen immer noch nicht angezeigt.Und natürlich schlägt die Lösung fehl, wenn Sie Ihr Passwort ändern.Aber gute Idee.+1 von mir.
Dies verhindert nicht Angriffe, die darauf beruhen, dass [der Benutzername falsch eingegeben wurde] (http://security.stackexchange.com/a/136483/56961).
Unter all den anderen Gründen, die ich für eine schlechte Idee halte, ist das Ver- und Entschlüsseln von Daten mit asymmetrischen Schlüsseln buchstäblich um Größenordnungen langsamer als die symmetrische Verschlüsselung.Die zusätzliche Belastung Ihrer Server wäre geradezu lächerlich.
@Craig Benötigt SSL nicht ungefähr dieselbe Last, wenn nicht mehr als die Verschlüsselung mit einer asymmetrischen Verschlüsselung?
SSL verwendet asymmetrische Verschlüsselung, um einen symmetrischen Verschlüsselungsschlüssel sicher zu generieren und gemeinsam zu nutzen, der dann zum Verschlüsseln aller übertragenen Daten verwendet wird.
Es ist durchaus möglich, dass es sehr spät war, als ich diesen Kommentar erstellt und strenger formuliert habe, als ich es sonst hätte tun können.:) :)
Viktor Toth
2016-09-11 09:53:30 UTC
view on stackexchange narkive permalink

Ich zögere, die bereits ausgezeichneten Antworten hier zu ergänzen, aber es gibt noch einen weiteren wichtigen Punkt. Wenn Sie nicht absolut sicher sind, dass Benutzer nur über HTTPS eine Verbindung zur Website herstellen (und ehrlich gesagt auch dann nicht), sollten Sie niemals die Möglichkeit haben, die falschen Passwörter anzuzeigen ... da diese niemals in der Website übertragen (verschlüsselt oder nicht) werden sollten erster Platz. Client-Systeme sollten nur so etwas wie einen gesalzenen Hash übertragen, nicht das eigentliche Passwort (in einer ordnungsgemäßen Implementierung, um sicherzustellen, dass der Hash selbst nicht zum Passwort wird, dh etwas, das gestohlen und wiederverwendet werden kann), um Abhörangriffe zu verhindern / p>

Und es spielt keine Rolle, dass die Site keine Finanztransaktionen verarbeitet. Sie möchten immer noch nicht, dass es das schwächste Glied in einer Kette wird.

Ich bin also voll und ganz mit Ihrem Hauptentwickler in dieser Sache einverstanden. Ich würde mit Zähnen und Nägeln gegen dieses "Merkmal" kämpfen.

Damit der Server den vom Client generierten gesalzenen Hash speichern muss?Wie unterscheidet sich dies funktional davon, das Passwort nur über einen sicheren Kanal zu senden und den Server es mit einem echten Passwort-Digest-Algorithmus wie pbkdf2, bcrypt oder scrypt hashen zu lassen, von denen keiner in den Webbrowsern (a) und (b) implementiert ist, wenn dieDer Client sendet einen Hash. Er beweist lediglich, dass er den Hash kennt und nicht, dass er das tatsächliche Kennwort kennt. Dies ist letztendlich weniger sicher als das Senden des Kennworts und die Durchführung einer echten Kryptografie auf dem Server.
Es gibt bscrypt / scrypt-Implementierungen in JavaScript.Durch doppeltes Hashing kann sichergestellt werden, dass das, was der Client sendet, nicht zum Kennwort wird (nicht wiederverwendet werden kann).Mein Anliegen bei jeder Implementierung wäre die Art und Weise, in der ein nicht vorhersehbares Salt für den zweiten Hash erstellt, gespeichert und an den Client gesendet wird.
Wenn der Server JavaScript an den Client sendet, um das Kennwort zu hashen, geben Sie dem Eigentümer des Servers immer noch das gleiche Maß an Vertrauen und bieten einem Mann in der Mitte die Möglichkeit, Ihnen ein geändertes Skript zu sendenAußerdem entfällt die Möglichkeit für den Server, das verwendete kryptografische Protokoll einfach zu versionieren, zu aktualisieren und zu steuern. Außerdem wird jedem potenziellen Angreifer genau angezeigt, welches Protokoll Sie verwenden und wie viele Runden usw. Ich sehe immer noch mehr Probleme als Vorteile, respektvoll.
Wenn ich Ihren Standpunkt richtig verstehe, sagen Sie, dass ein Mann in der Mitte die gleiche Möglichkeit hat, das Kennwort zu stehlen, als ob es ohne Hashing / Verschlüsselung gesendet worden wäre, da der JS selbst vom Server stammt.Daher wird ein sicherer Kanal benötigt, und ein sicherer Kanal verringert die Probleme, die mit dem Senden eines unverschlüsselten Kennworts verbunden sind.Habe ich deinen Standpunkt richtig verdaut?
Im Wesentlichen, aber das ist nur einer meiner Punkte.Dieser sichere Kanal ist HTTPS mit Vorwärtsgeheimnis und existiert bereits.Wenn ein Server Ihnen ein Skript zur Verarbeitung Ihres Kennworts sendet, kann der Server Ihr Kennwort auch nur verarbeiten, sofern der Kanal sicher ist.Es gibt keinen Nettogewinn durch Hashing auf dem Client, aber es gibt viele potenzielle Probleme mit Hashing auf dem Client.
Was ist mit den folgenden Bedenken: 1) Anstelle einer CPU haben jetzt zwei CPUs zumindest vorübergehend das Klartext-Passwort.2) Was ist, wenn der Kanal doch nicht sicher ist?Ist es sinnlos, auch über http einen "Goldstandard" für die sichere Authentifizierung festzulegen?Sind meine Prioritäten hier falsch platziert?
Wenn der Kanal nicht sicher ist, hilft Ihnen das Hashing auf dem Client nicht, da ein Mann in der Mitte den Hash leicht erfassen und wiedergeben kann.Wenn Sie ein Handshake-Protokoll entwickeln möchten, das ein wenig hin und her tanzt, um einen sicheren Austausch herzustellen, kann ich HTTPS vorschlagen?:-) Die CPU hält keine Informationen fest (abgesehen vom CPU-Cache, der während der Kontextwechsel möglicherweise geleert wird oder nicht, aber verwechseln wir uns nicht damit).RAM- und Festplatten-Caches sind jedoch sowohl auf dem Server * als auch auf dem * Client eine andere Sache.
Ich bin mit dem ersten Teil respektvoll nicht einverstanden, denn wenn der Server ein einmaliges Salt sendet und der Client mit diesem Salt hascht (dies ist der Punkt über doppeltes Hashing; erster Hash mit festem Salt, der zum Speichern des Passworts auf dem Server verwendet wurde).Zweitens: Hash mit einmaligem Salt (Server-Hashes mit demselben einmaligen Salt zum Vergleich). Der Hash kann durch Wiedergabe nicht wiederverwendet werden.Aber ich verstehe Ihre Punkte über Man-in-the-Middle-Angriffe.Denkanstöße, danke.
Wir haben die Warnung "Chat" erhalten.Was Sie jedoch vorschlagen, erfordert, dass der Server beide Salze an den Client weitergibt, da der Client sicherlich nicht damit rechnen kann, sich an das ursprüngliche Salz zu erinnern.Wenn der Kennwort-Hash ursprünglich auf dem Server gespeichert war, musste das Klartext-Kennwort an den Server übergeben oder der ursprüngliche gesalzene Hash gesendet werden, und er war abfangbar.Und wie ich bereits erwähnt habe, macht dies Dinge wie die Versionierung des Passwort-Hashing-Algorithmus schwieriger und fehleranfälliger.Ich sehe nur eine Menge Löcher darin.;-);
gnasher729
2016-09-10 20:21:29 UTC
view on stackexchange narkive permalink

Ihr System verfügt über eine große entschlüsselbare Datenbank mit Kennwörtern. Wenn Sie die falschen Passwörter für Benutzer X nachschlagen, erhalten Sie fast, aber nicht ganz korrekte Passwörter für das Konto von X, korrekte Passwörter für verschiedene Konten des Benutzers X sowie korrekte Passwörter für Konten von Benutzern mit fast demselben Benutzernamen wie X.

Mit der vernünftigen Annahme, dass ein Hacker in Ihr System eindringen und eine entschlüsselte Kopie der Datenbank erhalten könnte, wäre dies katastrophal. Selbst wenn der Zugriff der falschen Person auf Ihr System nicht zu kritisch ist, enthält diese Datenbank Kennwörter Ihrer Benutzer für verschiedene Systeme, die möglicherweise viel kritischer sind.

ddyer
2016-09-15 23:03:12 UTC
view on stackexchange narkive permalink

Es scheint mir, dass bei einer ordnungsgemäß erstellten Authentifizierung das vom Benutzer eingegebene Kennwort nicht einmal an die Host-Site übertragen wird, sodass die Frage nach dem Speichern falscher Versuche strittig ist.

Möglicherweise ist dies akzeptabel In der Benutzeroberfläche befindet sich ein Kontrollkästchen "Kennwort anzeigen", das ausschließlich eine lokale Funktion ist und entweder als eingegebenes Kennwort oder nach einem fehlgeschlagenen Versuch verwendet werden kann. Wahrscheinlich sollten die gespeicherten Informationen nach kurzer Zeit gelöscht werden, um das Ernten von Passwörtern von verlassenen Konsolen zu verhindern.

Huh?Das Passwort, das Sie auf einer Website eingeben, wird immer an den Host-Server übertragen, um überprüft zu werden.Ich kann dem Client nicht vertrauen, dass er sich gegen sich selbst authentifiziert, und clientseitiges Hashing / Verschleierung ist ziemlich sinnlos.Das Passwort wird hoffentlich mit SSL / TLS übertragen, daher wird es während der Übertragung verschlüsselt, aber es wird trotzdem an den Server gesendet.
Nein, eine Variation von;Der Server gibt Ihnen eine zufällige Zeichenfolge, Sie hashen das Kennwort mit der zufälligen Zeichenfolge und geben es an den Server zurück. Der Server vergleicht das, was Sie gesendet haben, mit dem erwarteten Ergebnis und beweist, dass Sie das Kennwort kennen.
Und beweisen, dass der Server alle Passwörter im Klartext speichert.Sonst kann es das Hashing nicht machen.Das ist also eine viel schlechtere Lösung.
Nicht unbedingt, es hängt vom genauen Hashing-Protokoll ab.Hash das Passwort zum Beispiel mit einer bekannten, festen Methode, die theoretisch reproduziert, was der Server speichert.Hashing dann das Ergebnis mit dem neu präsentierten Zufall (Vermeidung von Wiederholungsangriffen).
@ddyer Wie schlagen Sie vor, dass der Server das erwartete Ergebnis kennt, es sei denn, der Server hasht das Kennwort mit demselben Algorithmus, um den Vergleich durchzuführen?Bei HTTPS geht es um einen gut überprüften Handschlag, um einen sicheren Kanal einzurichten.Roll-Your-Own-Verschlüsselung ist schwer zu tun.
Der Server hatte also irgendwann das Klartext-Passwort, um das erste Hashing durchzuführen und es zu speichern.Oder der Client hat es bereits beim ersten Mal vorab gehasht.Aber in diesem Fall ist der Hash der Klartext, also ist das sinnlos.Nehmen wir jedoch an, der Server hat das erste Hashing aus dem echten Klartext durchgeführt, und der Client hat dasselbe getan.Führen Sie beim Anmelden jeweils eine zweite Runde mit einer vereinbarten Nonce durch und vergleichen Sie die Ergebnisse.Dann muss der Client die gesamte Hashing-Strategie des Servers kennen.Der Server kann keine Salze, Geheimnisse oder Algorithmen für sich behalten.Jeder Anmeldeversuch müsste alles offenlegen
Sie haben Recht, dass das Hash-Passwort effektiv das Passwort ist, aber die Frage ist, was schlimmer ist.Angenommen, das gespeicherte Kennwort des Servers ist kompromittiert, oder der vorübergehende Zugriff des Servers auf das Klartextkennwort (und fehlgeschlagene Kennwörter) ist ein Risiko.Beispielsweise hätten die jüngsten SSL-Hacks ergeben, dass Kennwörter "sicher" an den Server übertragen wurden, aber nur nutzlose Hashes, wenn das Protokoll niemals echte Kennwörter übertragen hätte.Am Ende hängt alles von Ihrem Bedrohungsmodell ab.


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