Frage:
Client-seitiges Passwort-Hashing
Foy Stip
2012-10-23 05:47:19 UTC
view on stackexchange narkive permalink

Bearbeiten : Aktualisiert, um das Ziel stärker zu betonen - Sicherheit für den Benutzer und keine Verbesserung der Sicherheit.

Nachher Wenn ich hier einige Diskussionen über das clientseitige Hashing von Passwörtern durchlese, frage ich mich immer noch, ob es in einer bestimmten Situation in Ordnung sein könnte, es zu verwenden.

Insbesondere hätte ich gerne den Client - ein Java-Programm - Hash ihr Passwort mit etwas wie PBKDF2, wobei eine Kombination aus ihrer E-Mail-Adresse und einem konstanten anwendungsspezifischen Byte-Block als Salt verwendet wird. Die Idee ist, dass der Hash für die Authentifizierung reproduzierbar ist, aber hoffentlich nicht anfällig für Reverse-Engineering-Angriffe (um das wörtliche Kennwort zu ermitteln) außer Brute Force ist, wenn die Serverdaten kompromittiert werden.

Ziel:

Das clientseitige Hashing dient dem Benutzer zur Gewissheit, dass sein wörtliches Kennwort niemals vom Server empfangen wird, selbst wenn die Gewissheit besteht, dass es ohnehin im Speicher gehasht wird. Ein weiterer Nebeneffekt (oder möglicherweise eine Haftung?) Besteht darin, dass die Hashing-Kosten für ein iteriertes PBKDF2 oder ähnliches beim Client liegen.

Die Umgebungsmerkmale sind:

  • Die gesamte Client-Server-Kommunikation ist verschlüsselt.
  • Wiedergegebene Nachrichten sind nicht zulässig. dh. Der vom Client gesendete Hash kann von einem Lauscher nicht effektiv als Kennwort verwendet werden.
  • Temp-Banning und Blacklisting von IPs sind für mehrere erfolglose Anmeldeversuche innerhalb eines kurzen Zeitraums möglich. Dies kann pro Benutzerkonto oder systemweit erfolgen.
  • ol>

    Bedenken:

    1. "Vermeiden Sie die Entwicklung hausgemachter Authentifizierungsschemata."
    2. Das Salz ist für jeden Benutzer deterministisch, auch wenn die erzeugten Hashes aufgrund der (identischen) zusätzlichen Bytes, die in das Salz geworfen werden, für diese Anwendung spezifisch sind. Ist das schlecht?
    3. Authentifizierungen auf der Serverseite erfolgen ohne nennenswerte Verzögerung und ohne Hashing-Kosten. Erhöht dies die Anfälligkeit für verteilte Brute-Force-Authentifizierungsangriffe?
    4. Rogue-Clients können einen schwachen Hash für ihre eigenen Konten bereitstellen. Eigentlich keine allzu große Sorge.
    5. Sollte der Server die Client-Hashes vor dem Speichern erneut aufbereiten?
    6. ol>

      Gedanken?

    Ich glaube, ich bin etwas verwirrt über das Bedrohungsmodell. Was ist die Bedrohung, gegen die sich dies verteidigt? Ist das Passwort auf dem Server gespeichert? Wenn nicht, ist das vom Client an den Server übergebene Token das Kennwort. Wenn dies nicht der Fall ist, wie können Sie Wiederholungsangriffe verhindern? Ich sehe hier Dinge, die mir gefallen, aber ich kann das Schema nicht bewerten, ohne das Bedrohungsmodell zu verstehen.
    Tut mir leid, ich hätte wirklich den dritten .. jetzt vierten Absatz mehr betonen sollen, der das Ziel dieses Schemas im Vergleich zu einem konventionelleren Schema umreißt: Seelenfrieden für den Benutzer auf dem Server, der sein wörtliches Passwort nicht erhält. Der Server, der keinen teuren PBKDF2-Hash ausführen muss, der über n Iterationen ausgeführt wird, ist ein Bonus (obwohl, wie ein Poster gezeigt hat, dies auch die Verteidigung gegen DOS verbessern könnte). Ich versuche jedoch nicht, ein anderes als das übliche Bedrohungsmodell zu berücksichtigen.
    Sieben antworten:
    #1
    +47
    David Wachtfogel
    2012-10-23 09:54:22 UTC
    view on stackexchange narkive permalink

    Hashing auf der Clientseite löst nicht das Hauptproblem, das durch das Passwort-Hashing gelöst werden soll. Was passiert, wenn ein Angreifer Zugriff auf die Datenbank mit gehashten Passwörtern erhält? Da die von den Clients gesendeten (gehashten) Kennwörter unverändert in der Datenbank gespeichert werden, kann sich ein solcher Angreifer als alle Benutzer ausgeben, indem er dem Server die gehashten Kennwörter unverändert aus der Datenbank sendet.

    Zum anderen Hashing auf der Clientseite ist insofern hilfreich, als es dem Benutzer sicherstellt, dass der Server das Kennwort nicht kennt - was nützlich ist, wenn der Benutzer dasselbe Kennwort für mehrere Dienste verwendet (wie die meisten Benutzer) ).

    Eine mögliche Lösung hierfür ist das Hashing sowohl auf der Client- als auch auf der Serverseite. Sie können die schwere PBKDF2-Operation weiterhin auf den Client auslagern und auf der Serverseite eine einzelne Hash-Operation (auf der Clientseite PBKDF2-Hash-Kennwort) ausführen. Das PBKDF2 im Client verhindert Wörterbuchangriffe und die einzelne Hash-Operation auf der Serverseite verhindert, dass die Hash-Passwörter aus einer gestohlenen Datenbank unverändert verwendet werden.

    Sie haben Recht, es gibt den zwingenden Grund, den Server erneut zu hashen: Wenn ein Angreifer eine Kopie der Datenbank erhält, ohne unbedingt Schreibzugriff zu haben, wenn ich Sie richtig verstehe. Aufgrund der bisherigen Antworten anderer bin ich immer noch besorgt über die Realisierbarkeit dieses gesamten Schemas, aber im Moment scheint es, als ob die Kombination aus einem schweren Hash auf dem Client und einem endgültigen Re-Hash auf dem Server vielversprechend klingt. Danke für die Antwort.
    Anderer Grund, clientseitig zu hashen? Wenn jemand Anmelde- und Routineaufgaben in Ihrer App automatisieren möchte (z. B. in einem Cron-Job) und kein Hashing verwendet, muss er das Kennwort im Klartext irgendwo auf dem Laufwerk speichern. Sicher, sie könnten es verschlüsseln, aber dann müssten sie da sein, um den Verschlüsselungsschlüssel einzugeben, so dass es das gleiche Maß an Unannehmlichkeiten bedeutet.
    Und das Argument gegen das Hashing auf der Clientseite - dass es das durch das Hashing auf der Serverseite gelöste Problem nicht löst - ist spuriouis. Die clientseitige Hashing-Ebene kann transparent sein und keinen Aspekt des Backends beeinflussen. Alles, was clientseitig gehasht wird, ist, Eves Leben zu erschweren, und dies zu minimalen Kosten für den Endbenutzer.
    Zum Teufel, man könnte sogar eine einzige Iteration von MD5 auf dem Client durchführen und sicher sein.Mit einem vollständig zufälligen Hash, der vom Client eingeht, steht auf der Serverseite ein riesiger Suchbereich zum erneuten Aufbereiten zur Verfügung.Selbst superschnelles MD5 wird noch sehr lange brauchen, um den gesamten Raum zu durchsuchen.
    @JasonCoyne Wenn der Client nur einen einzelnen MD5 und der Server nur einen weiteren einzelnen MD5-Hash für das Ergebnis ausführt, kann ein Angreifer, der Zugriff auf die Hash-Kennwort-DB des Servers erhält, einen einfachen Angriff ausführen (sogar unter der Annahme von Salt).Nehmen Sie für jedes Hash-Passwort in der Datenbank die beliebtesten Passwörter, hacken Sie sie zweimal und vergleichen Sie sie mit dem Hash-Passwort in der Datenbank.Selbst wenn Sie die 10 Millionen beliebtesten Kennwörter verwenden, dauert die Ausführung jedes Hash-Kennworts in der Datenbank weniger als eine Sekunde.
    Ich frage mich, warum dies kein gesunder Menschenverstand ist. Ich meine, Browser sollten Warnungen ausgeben, wenn Sie eine Passworteingabe im Klartext senden.Was ist, wenn ich xyz.com nicht vertraue?Ich meine, ich verwende bereits zufällige Passwörter, aber die meisten Leute haben 3 Passwörter und vorsichtige 4.
    @DavidWachtfogel Nehmen Sie niemals einen bestimmten Kunden an.Wenn Sie das schwere Hashing auf den Client verlagern, fällt es Angreifern mit spezieller Hardware leicht, und Benutzern mit schlechter Hardware fällt es schwer.Genau das Gegenteil von dem, was Sie wollen.Der bullige Hash sollte sich auf dem Server befinden, da Sie diese Hardware kennen, und der schnelle, beruhigende Hash sollte sich auf dem Client befinden.
    Hashing ist nicht der richtige Weg, um Anmeldeinformationen zu schützen.Verschlüsselung ist.Wenn Sie einen reinen Hash auf dem Client machen, dann bekommt ein Angreifer nicht das Plaintext-Passwort, aber sie könnten noch einen Replay-Angriff machen.Sie benötigen mindestens ein sitzungsspezifisches Salt im Hash, um Wiederholungsangriffe zu verhindern, die man als schwache Form der (Einweg-) Verschlüsselung nennen könnte.Aber besser für die richtige Verschlüsselung gehen.Welche SSL / TLS / HTTPS / IPSec sollen dir geben.
    Auf der Serverseite muss man noch Salz verwenden.
    #2
    +13
    Motoma
    2012-10-23 18:42:19 UTC
    view on stackexchange narkive permalink

    Es gibt nur wenige Zeiten, in denen sich clientseitiges Hashing lohnt. Ein solcher Umstand ist, wenn der Hash-Prozess rechenintensiv ist, was bei PBKDF2 der Fall sein kann.

    Beheben Ihrer Bedenken:

    1. Vermeiden Sie dies ebenfalls nicht validierte Vorschläge zur Kryptographie finden Sie im Internet. (Haftungsausschluss: Ich bin nicht Bruce Schneier.)
    2. Deterministische Salze sind kein Problem - die einzige wirkliche Anforderung an das Salz ist, dass es für jeden Benutzer einzigartig ist. Der eigentliche Zweck des Salt besteht darin, zu verhindern, dass eine Brute Force für ein Kennwort bei einer kompromittierten Datenbank zu einer Brute Force für alle Kennwörter wird. Selbst wenn Sie ein zufälliges Salt direkt neben dem Hash-Passwort in Ihrer Datenbank speichern würden, würden Sie dieses Ziel dennoch erreichen, vorausgesetzt, jeder Benutzer ist anders.
    3. Wie oben erwähnt, ist PBKDF2 nett, weil Sie es willkürlich können Entscheide die Rechenschwierigkeit des Hash. Sie können ein c so auswählen, dass ein einzelner Hash auf moderner Hardware Sekunden dauert, wodurch das Risiko eines Brute-Force-Angriffs auf API-Ebene effektiv ausgeschlossen wird. (Natürlich kann es sein, dass Ihre Kunden beim Anmelden keine so lange Verzögerung haben.)
    4. Ein Benutzer kann einfache Passwörter auswählen - er verletzt sich nur selbst. Wenn Sie dieses Risiko beseitigen möchten, muss der Server den Hash zum ersten Mal generieren, vorausgesetzt, das Kennwort wird über einen verschlüsselten Kanal übertragen.
    5. Ja, und Sie müssen diese auch eindeutig salzen. Im Falle eines Datenbankkompromisses möchten Sie sicherstellen, dass der Angreifer keine Informationen erhält, mit denen er sich direkt als Benutzer auf Ihrem System authentifizieren kann. Eine Einschränkung hierbei ist, dass Sie nicht möchten, dass Ihr serverseitiges Hashing so rechenintensiv ist wie Ihr clientseitiges Hash. Wenn Ihr serverseitiger Hash zu viel Aufwand erfordert, öffnen Sie sich einem CPU-anstrengenden Denial-of-Service-Angriffsvektor - ein Angreifer spammt einfach leere Kennwortauthentifizierungsversuche über Tor, Kennwörter, die Ihr Server Hashing versuchen muss, bevor er weiß, dass dies der Fall ist betrügerisch und hinterlässt schließlich einen überlasteten Server.
    6. ol>
    Vielen Dank für die Eingabe zu all diesen Punkten. Betreff: Punkt 2, ja das war / ist mein Verständnis .. dass es in Ordnung wäre, solange die Salze immer unterschiedlich sind. Für dieses Schema ist das Salz für verschiedene E-Mails unterschiedlich und auch für dieselben E-Mails in verschiedenen Anwendungen / Datenbanken.
    Ja, wie Sie und andere bereits betont haben, ist ein erneutes Hashing auf dem Server auf jeden Fall erforderlich, obwohl dies, wie Sie sagen, billiger durchgeführt wird. Hmm .. Tor-Anfragen von demselben Benutzer oder von verschiedenen Computern hinter demselben NAT-Router scheinen von verschiedenen IPs zu stammen, nicht wahr?
    Ja, es gibt einfache Tools, mit denen mehrere Anforderungen von einem einzelnen Computer über mehrere Tor-Exit-Knoten geleitet werden können.
    #3
    +9
    ddyer
    2012-10-23 12:04:17 UTC
    view on stackexchange narkive permalink

    Wenn Sie das Kennwort auf der Clientseite hashen, ist das Ergebnis unabhängig vom Ergebnis das Kennwort, sodass Sie keine echte Sicherheit erhalten. Jeder Hack oder Informationsleck, der das Klartext-Passwort enthüllt hätte, enthüllt stattdessen das Hash-Passwort, das das echte Passwort ist.

    Dies sollte nicht mit wissensfreien Authentifizierungsschemata verwechselt werden, bei denen ein Austausch von Nachrichten beweisen, dass der Client das echte Passwort kennt, ohne es tatsächlich zu übertragen.

    Wenn Sie meinen, dass die Datenbank des Servers kompromittiert wird, wie David Wachtfogel betonte, dann haben Sie Recht, dass der Hash einfach als Passwort erneut übertragen werden kann. Es muss auf dem Server erneut gehasht werden. Der Gewinn ist keine erhöhte Sicherheit, sondern ein beruhigendes Gefühl für den Benutzer auf dem Server, der kein wörtliches Passwort erhält. Wenn Sie andererseits Man-in-the-Middle-Angriffe meinen, schützt das zugrunde liegende Verschlüsselungsschema vor der Wiedergabe von irgendetwas, sei es wörtliche oder gehashte Passwörter.
    Entschuldigung, aber "zeigt stattdessen das Hash-Passwort an, das das echte Passwort ist" ist aus Anwendersicht nicht wirklich wahr.Wenn es ein Leck gibt, würde jeder Benutzer lieber ein Hash-Passwort als ein einfaches Passwort verlieren, insbesondere wenn er dasselbe Passwort für verschiedene Dienste verwendet, was viele Benutzer leider tun. Daher ist es am besten, wenn das Passwort sowohl auf Client- als auch auf Serverseite gehasht wird.
    #4
    +7
    Stephen Touset
    2012-10-24 01:02:22 UTC
    view on stackexchange narkive permalink

    Anscheinend versuchen Sie, Ihr eigenes kryptografisches Protokoll zu erfinden. Aus der Beschreibung Ihres Ansatzes geht hervor, dass Sie nicht den Hintergrund haben, dies auf sichere Weise zu tun. Ich empfehle dringend, vorhandene Protokolle zu verwenden, anstatt eigene zu erstellen.

    Erstens ist nicht klar, welches Bedrohungsmodell Sie Ihrer Meinung nach umgehen. Sie zitieren einen sogenannten "Reverse-Engineering-Angriff", der keine wirkliche Definition oder Bedeutung hat.

    Zweitens scheint Ihr Verständnis für den Zweck und die Best Practices eines Salzes für seine Erzeugung zu fehlen. Salze müssen nicht geheim gehalten werden. Sie können (und sollten) für jedes neue Authentifizierungstoken ein eindeutiges Salt aus einem CSPRNG generieren und nicht aus einer E-Mail-Adresse (die sich möglicherweise ändert). Feste anwendungsspezifische Salze werden manchmal als "Paprika" bezeichnet, und mir ist keine kryptografische Literatur bekannt, die ihre Verwendung unterstützt oder fördert.

    Drittens ist PBKDF2 in Ordnung, aber im Ernst, verwenden Sie BCrypt. BCrypt wurde dafür entwickelt und ist weit verbreitet. Gute BCrypt-Implementierungen übernehmen für Sie die Salzgenerierung und die Kalibrierung / automatische Erkennung von Arbeitsfaktoren. Sie müssen diese Dinge selbst implementieren, um PBKDF2 verwenden zu können, und Sie werden fast unweigerlich Fehler machen.

    Viertens gibt es einen bestehenden Ansatz für das, was Sie anscheinend zu tun versuchen. Die wissensfreie Authentifizierung kann mit SRP durchgeführt werden. Das Passwort des Benutzers wird niemals über das Kabel übertragen, und ein Mann in der Mitte kann nichts Nützliches riechen, mit dem er sich authentifizieren kann. Es ist jedoch anscheinend schwierig, sie korrekt zu implementieren, und es gibt nicht viele vorhandene Bibliotheken, die Ihnen einen Hinweis darauf geben sollten, wie schwierig das Problem tatsächlich ist.

    Lange Rede, kurzer Sinn: Erfinden Sie Ihre nicht eigene Krypto. Verwenden Sie Lösungen und Protokolle, die weit verbreitet sind und den Test der Zeit überstanden haben.

    Ja, ich bin sehr vorsichtig, wenn ich Dinge außerhalb etablierter Protokolle mache, aber wenn ein clientseitiger Hash des Passworts (im Gegensatz zum Senden in wörtlicher Form, obwohl immer noch verschlüsselt und nicht verschlüsselt) ein Nein-Nein ist, würde ich gerne helfen, zu verstehen, warum es so ist Schlecht. Ich habe die Frage bearbeitet, um das Ziel stärker zu betonen: Sicherheit für den Benutzer, wenn sein wörtliches Passwort nicht vom Server empfangen wird.
    Im Falle einer geänderten E-Mail müsste der Benutzer zu diesem Zeitpunkt sein Passwort eingeben, damit es erneut gehasht werden kann. Andernfalls sollte dies in Ordnung sein. Das Salz unterscheidet sich für verschiedene E-Mails und von dem, das in anderen Anwendungen verwendet wird, aufgrund des festen zusätzlichen Salzes, das (spezifisch für diese App) für jeden Hash eingeworfen wird. Auch BCrypt ist definitiv eine Möglichkeit, die ich in Betracht ziehen werde. Danke für deine Gedanken.
    Der allererste Grund, warum es ein Nein-Nein ist, ist, dass Sie * es * falsch verstehen werden. Ich meine damit keine Beleidigung, aber es gibt einfach zu viele Orte, um einen kritischen Fehler zu machen, als dass Sie eine vernünftige Erfolgserwartung hätten. Unabhängig davon, welche Sicherheit durch das Nicht-Senden des Kennworts über das Netzwerk erzielt werden kann, wird dies gelöscht, sobald Sie den Digest mit dem gespeicherten Wert in der Datenbank oder der integrierten Zeichenfolgenvergleichsfunktion Ihrer Sprache vergleichen. Oder wenn Sie bei einer von zwölf anderen Operationen einen Fehler machen.
    Ein weiterer Grund ist, dass ein Angreifer jetzt über Lesezugriff auf die Datenbank verfügt, um sich als Benutzer auszugeben. Bei Sicherheit geht es um Tiefenverteidigung - um die Sicherheit der Ebenen, sodass ein Angreifer, der einen Fehler in einer Sicherheitsstufe ausnutzt, immer noch durch tiefere Ebenen behindert wird. Die Umwandlung eines großen Sicherheitsfehlers in einen absolut kritischen ist das genaue Gegenteil dieses Ziels.
    Keine Beleidigung, ich schätze die Warnung und Ihre Zeit, um über das Problem nachzudenken. Ich bin vorsichtig mit jedem Schema, das ungewöhnlich erscheint, daher meine erste Sorge im OP. Nach allem, was Sie sagen, sollte ich mich unsicher fühlen, wenn ich überhaupt etwas über einen verschlüsselten, wiedergabegeschützten Stream sende? dh. das Protokoll, das sich unter dieser Clientauthentifizierung befindet? Um mir das Verständnis zu erleichtern, was sind einige spezifische Fallstricke für diesen Fall? Sie haben Recht mit dem Lesezugriff auf die Datenbank, der effektiv eine kostenlose Anmeldung ermöglicht. Würde ein (leichter) Re-Hash auf dem Server dies abschwächen?
    Ja, aber Sie spielen mit Sicherheitslücken. SSL ist vollkommen in Ordnung, um vertrauliche Informationen zu senden. PBKDF2 ist vollkommen in Ordnung, um Passwörter zu verschleiern (aber BCrypt ist wahrscheinlich besser). Aber es ist die Implementierung von * allem anderen *, die schwach sein wird. Sie denken zu wenig über das Problem für Ihre Kompetenz nach. Sie sollten Authentifizierungsprotokolle nicht selbst entwerfen, sondern aus bereits vorhandenen Ansätzen auswählen, die von Fachleuten entwickelt wurden und den Test der Zeit überstanden haben.
    Wie wollen Sie beispielsweise die über das Kabel empfangenen Authentifizierungsdaten überprüfen? `SELECT * FROM users WHERE email =? AND password_digest =? `?. Laden Sie den Benutzer zuerst per E-Mail und führen Sie `user.password_digest == params ['password_digest']` aus? Sie haben gerade einem Angreifer erlaubt, sich als Benutzer zu authentifizieren. Wenn Sie nicht sofort verstehen, warum, sollte dies ein starkes Warnsignal dafür sein, dass Sie blind durch ein Minenfeld gehen.
    Sprechen Sie über SQL oder andere Arten der Code-Injection?
    Nein, aber diese Ansätze sind beide anfällig für Timing-Angriffe. Nach einigem Nachdenken denke ich, dass Sie dies aus der falschen Perspektive betrachten. Sie sollten nicht die Frage stellen: "Inwiefern ist das von mir erfundene Schema unsicher?" Es sollte * als * unsicher angenommen werden und das Ziel sollte sein, etwas anderes zu demonstrieren.
    Ich versuche, die Denkweise eines Angreifers zu übernehmen, aber vielleicht habe ich mich zu sehr auf Möglichkeiten wie DDOS konzentriert, während ich andere offensichtliche Lücken verpasst habe. Aber deshalb bitte ich hier auch um Feedback von Experten. Ich würde viel lieber hier abgeschossen als auf einem Live-Server.
    Sind Timing-Angriffe über eine Internetverbindung möglich, selbst auf einem Server mit geringer oder konstanter Last? Ich bin mir nicht sicher, ob selbst Anforderungen mit identischer Nutzlast unter Verwendung eines herkömmlichen oder eines langsamen Gleichgewichts einen Fehler auf dem Radar verursachen würden, wenn Sie die variablen Codepfade (sichere Zufalls- und Hash-Tabellen-Buckets) und die Thread-Wachsamkeit berücksichtigen, die alle auf einem Koloss ausgeführt werden wie Java, wo hinter den Kulissen viel passiert. Es ist jedoch eine interessante Möglichkeit.
    [Sie sind] (http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf), so Stanford-Forscher. Die richtige Lösung besteht darin, einen Vergleichsalgorithmus mit konstanter Zeit zu verwenden. Sperren nach fehlgeschlagenen Versuchen tragen ebenfalls zur Minderung des Problems bei. Es ist jedoch am besten, das Grundproblem einfach zu beheben. Die Richtlinien für Sperren können sich in Zukunft ändern. Es ging jedoch nicht um den einen Angriff, sondern darum, dass dieses Zeug * schwer * ist und es unzählige Möglichkeiten gibt, es durcheinander zu bringen. Arbeiten Sie nach Möglichkeit mit Konstrukten auf hoher Ebene (z. B. "Benutzer authentifizieren") anstelle von Konstrukten auf niedriger Ebene ("AES" oder "PBKDF2").
    Ja. Trotz Ihrer Erkenntnisse bin ich ehrlich gesagt immer noch geneigt, mit dem clientseitigen Hashing für dieses spezielle Projekt fortzufahren, da es eher eine Lernübung als etwas unternehmenskritisches ist. Diese Stanford-Studie war interessant, zumindest die nicht-mathematischen Teile, die ich verstehen konnte. Ich frage mich, ob Angreifer versuchen müssen, Hosting auf derselben Colocation wie ihr Ziel zu erhalten, um eine erstklassige Netzwerkposition für das Timing zu erhalten. Trotzdem nochmals vielen Dank für all Ihre Zeit und Ihre Erkenntnisse, sehr geschätzt.
    #5
    +6
    Thomas Pornin
    2013-02-24 04:54:39 UTC
    view on stackexchange narkive permalink

    Hashing auf dem Client kann unter bestimmten Umständen und aus bestimmten Gründen eine gute Idee sein, aber ich würde "Seelenfrieden des Benutzers" nicht zu einer davon machen. Ich bin alle dafür, dass Benutzer in einer harmonischen Stimmung und eins mit dem Universum sind, aber ich finde die Idee, zu fördern , zweifelhaft, um Benutzer dazu zu bewegen, dasselbe Passwort auf mehreren Websites wiederzuverwenden.

    Ein guter Fall für clientseitiges Hashing ist die Funktionsweise einiger "Passwort-Safes": Sie berechnen ein ortsspezifisches Passwort, indem sie das "Hauptkennwort" des Benutzers zusammen mit dem Site-Namen hashen. Dies bietet den größten Teil der Benutzerfreundlichkeit, immer überall dasselbe Kennwort zu verwenden, ohne Ihr Hauptkennwort tatsächlich Dutzenden unterschiedlicher Websites zuzuweisen. Dies funktioniert jedoch nur, solange der Algorithmus zur Kennwortableitung generisch ist und sich nicht ändert. Dies scheint von einer Webbrowser-Erweiterung viel besser angegangen zu werden als von einem Applet, das von den Sites selbst stammt (alle Sites müssten zusammenarbeiten, um Applets zu verwenden, die denselben Algorithmus zur Kennwortableitung mit ortsspezifischen Daten verwenden) / p>

    Ein weiterer guter Fall für clientseitiges Passwort-Hashing ist die Verwendung eines langsamen Hash (um das Knacken von Passwörtern für einen Angreifer zu erschweren, der eine Kopie der Hash-Datenbank abrufen könnte Passwörter); Es ist verlockend zu versuchen, die Kosten auf den Client zu verlagern, da der Client, wenn er eine Verbindung herstellen möchte, meistens untätig ist und aktiv an einer Verbindung interessiert ist. Langsames Hashing ist jedoch ein Wettrüsten zwischen Angreifer und Verteidiger. Die Verwendung von Java führt zu einer Verlangsamung (um den typischen Faktor 3), und einige Client-Systeme können recht schwach sein (z. B. billige Smartphones oder zehn Jahre alte Computer). Dies ist so, als würde man ein Schwert anstelle eines Sturmgewehrs aufheben, bevor man in eine Schlacht eintritt, in der der Gegner einen Panzer mitbringt.

    Wenn Sie als Benutzer Ihr Kennwort jedoch vor schlampigen Speicherprozeduren durch eine Site schützen möchten, sollten Sie für jede Site ein anderes Passwort auswählen . (Ich persönlich behalte eine Datei mit Passwörtern und alle meine Passwörter werden zufällig generiert.)

    Vielen Dank, dass Sie sich die Zeit genommen haben, Ihre Experteneinblicke (ich habe viele Ihrer anderen Beiträge gelesen) zu dieser Frage zu teilen, und es tut mir leid, dass Sie so lange gebraucht haben, um zu antworten - ich hüpfe hier nicht sehr oft. Nachdem ich die Überlegungen abgewogen hatte, implementierte ich das clientseitige Hashing und gab der Versuchung nach, die Kosten eines langsamen Hashs auf den Client zu verlagern (wie Sie sagen), da der Server den Umgang mit unformatierten Passwörtern vermeidet. Wie ich mich im OP gefragt habe und auch, wie jemand betonte, ist ohnehin eine serverseitige Aufarbeitung erforderlich, wenn auch eine leichtere als PBKDF2.
    #6
    +4
    goodguys_activate
    2012-10-23 18:54:30 UTC
    view on stackexchange narkive permalink

    Ein Google-Mitarbeiter arbeitet an etwas Ähnlichem namens TLS-OBC. Mit diesem RFC-Entwurf kann der Client das Kennwort hashen und an eine TLS-Sitzung binden.

    Insbesondere könnten Sie an dieser Website http://www.browserauth.net/origin-bound-certificates

    und diesem Link auf Strong User interessiert sein Authentifizierung http://www.browserauth.net/strong-user-authentication

    ::Update

    OBC und möglicherweise die andere ist jetzt integriert der FIDO-Authentifizierungsstandard.

    Danke für die Links, es sieht interessant aus. Können Sie einen Link zu einigen Informationen über den clientseitigen Aspekt des Passwort-Hashing bereitstellen?
    #7
    +2
    Luc
    2019-01-09 16:19:17 UTC
    view on stackexchange narkive permalink

    Passwort-Hashing verhindert, dass jemand außer dem Benutzer das Passwort lernt. Menschen verwenden Passwörter wieder und sind normalerweise nicht sehr stark, wenn sie auswendig gelernt werden. Aus diesem Grund beschäftigen wir uns mit langsamen Hashes (Bcrypt, Scrypt, Argon2 usw.) anstelle eines schnellen Hashs: Es schützt das Kennwort des Benutzers besser, obwohl es für die Anwendung keinen Nutzen hat. Ein sekundärer Vorteil des Server-Hashs eines eingehenden Kennworts vor dem Speichern in der Datenbank besteht darin, dass sich jemand, der die Datenbank kompromittiert, nicht mit einem der gefundenen Werte anmelden kann (er muss sie zuerst knacken).

    Wir wollen beide Vorteile behalten. Zu diesem Zweck sollten wir auf dem Client (langsam) und auf dem Server (schnell) hashen.

    Warum auf dem Server?
    Ein Angreifer, der die Datenbank erhalten hat, kann die erhaltenen Daten nicht zum Anmelden verwenden. Wenn Ihr Client bereits einen langsamen Hash ausführt, kann dies eine einzelne Runde eines sicheren Hashing-Algorithmus (wie SHA-3 oder BLAKE2) sein.

    Warum auf dem Client?

    1. Transparenz
      Wenn ein Unternehmen gehackt wird, müssen wir hoffen, dass es uns mitteilt, wie die Passwörter waren gehasht, wenn überhaupt. Es gibt immer noch Orte, an denen sie Klartext speichern oder einen schnellen Algorithmus verwenden oder sie nicht salzen usw. Durch Hashing auf der Clientseite können Interessierte sehen, wie es gemacht wird, und Fragen wie diese a verhindern >. Meine Mutter wird es nicht überprüfen, aber meine Mutter überprüft auch nicht das TLS einer Website auf Herzblut: "Ethische Hacker" oder White-Hat-Hacker tun dies.

    2. Laden Sie den Server herunter
      Ein Risiko für sehr langsame Hashes auf dem Server besteht darin, dass ein Angreifer ihn für einen Denial-of-Service-Angriff verwenden kann: Wenn der Server 2 Sekunden benötigt, um jeden Anmeldeversuch zu verarbeiten, haben Angreifer einen großen Vorteil beim Versuch, ihn auszuschalten. Indem Sie den langsamen Hash auf dem Client ausführen (dessen CPU ohnehin zu 99% nicht verwendet wird und es nicht so ist, als würden sich die meisten Benutzer mehr als ein paar Mal pro Tag anmelden), entladen Sie den Server und können langsamere Hashes auswählen ohne zu riskieren, dass ein Angreifer Ihren Server herunterfährt.

    3. Reduzieren Sie die Auswirkungen einer beeinträchtigten Übertragung.
      Wenn der sichere Übertragungskanal aus irgendeinem Grund ausfällt, z. B. ein Fehler TLS (Juni 2020: "Hoppla, in den letzten 10 Versionen konnten die meisten TLS 1.0–1.2-Verbindungen passiv entschlüsselt werden") wird die Auswirkung verringert, da ein Angreifer nur die Hashes anstelle des ursprünglichen Kennworts beobachten kann . Dies gilt auch, wenn jemand Jahre später in der Lage ist, einen verschlüsselten Stream zu entschlüsseln, beispielsweise weil bekannt ist, dass RC4 vor mehr als einigen Jahren defekt ist.
      Beachten Sie, dass die Authentifizierung im Fehler vom Juni 2020 anscheinend nicht funktioniert betroffen sein, sodass Angreifer die JavaScript-Dateien nicht ändern konnten, um das Hashing zu entfernen. Jetzt muss ich mich fragen, welche Passwörter ich seit den letzten Monaten über https verwendet habe und ob eine dieser Verbindungen möglicherweise passiv abgefangen wurde.

    4. Verbessern Sie den Standard
      Now Damit wir die Umsetzung aller sehen können, wird diskutiert, wer am längsten und wer am besten ist. Diese Diskussion drängt definitiv die Schlechten, es besser zu machen, und führt wahrscheinlich auch zu einer Standardisierung. Es wäre wirklich ordentlich, wenn Sie dem Kennworteingabeelement nur einen Parameter hinzufügen könnten, z. B. <input type = password hash = v1> , der das gesamte Hashing für Sie erledigt (es würde mit dem Domainnamen salzen und Feld für den Benutzernamen, aber all diese Details dieses Vorschlags gehen über den Rahmen dieser Antwort hinaus.

    5. Erkennung eines Kompromisses
      Ein häufiges Argument lautet: "Wenn der Server kompromittiert wird, können Angreifer den JavaScript-Code entfernen, der für das Hashing des Kennworts verantwortlich ist, sodass die Angreifer den Klartext trotzdem erhalten können." Dieses Argument gilt nur für Websites, aber die Leute erwähnen dies normalerweise nicht, was dazu führt, dass auch in Anwendungen niemand clientseitig hascht. Was sie außerdem vergessen, ist, dass Sicherheitsforscher damit beginnen können, wenn clientseitiges Hashing üblich ist: Es wird Leute geben, die wichtige Websites scannen, um festzustellen, ob das Hashing noch vorhanden ist (dies wäre ein Indikator für einen Kompromiss, wenn PayPal entfernt wird clientseitiges Hashing (in dem hypothetischen Fall, dass sie in erster Linie clientseitiges Hashing durchführen würden), und es könnte Browsererweiterungen (oder integrierte Funktionen) geben, die Sie warnen, wenn es entfernt wird, genau wie wir vor der Anmeldung warnen Formulare auf http-Seiten.

    6. Kein geheimes Snooping
      Selbst wenn sie die Datenbank hashen, können Mitarbeiter das Kennwort abfangen, bevor es gehasht und gespeichert wird (indem sie sich bei einem TLS anmelden Endpunkt oder durch Installation eines zusätzlichen Codes). Es gibt genug Geschichten von sauren Mitarbeitern oder sogar Teenagern, die eine Anwendung erstellen und wissen möchten, wie die Passwörter ihrer Benutzer lauten.

    7. Keine Klartext-E-Mails
      Wenn der Server dies nicht tut Wenn Sie Ihr Passwort haben, können sie Ihnen keine E-Mails wie "Vielen Dank für Ihre Registrierung, Ihr Benutzername und Ihr Passwort sind xxx" senden. E-Mails werden allgemein als unsicher angesehen, aber es gibt immer noch Websites, die dies tun.

    8. Keine versehentliche Exposition
      Vor kurzem gab es einen Vorfall, bei dem Passwörter versehentlich in Protokolldateien geschrieben wurden. Ich werde den Firmennamen nicht erwähnen, weil ich ihn nicht für relevant halte, aber es war ein großes Technologieunternehmen mit einem engagierten Sicherheitsteam und allem. Unfälle wie diese passieren einfach und es gab einen ziemlich großen Medienausfall. In vielen Netzwerken, in denen ein separates System die TLS-Terminierung durchführt und dann den Anforderungs-Klartext an andere Systeme sendet, besteht zusätzlich eine Gefährdung, sodass jede Netzwerkbox die Kennwörter sehen kann (Google hat dies verwendet, bis die NSA Wind in ihren internen Abschnitten hatte) Netzwerk). Das Abfangen von "Klartext" -Kennwörtern wäre weniger problematisch, wenn wir das Hashing durchführen würden, bevor das Kennwort das Netzwerk erreicht.

    9. Warum nicht?
      Ich kann mir keinen Grund vorstellen warum Sie es nicht tun sollten, vorausgesetzt, Sie führen zusätzlich einen schnellen Hash auf dem Server durch (um den im ersten Absatz genannten sekundären Vorteil zu erhalten). Selbst wenn Sie der Meinung sind, dass nur einer der Gründe zwingend ist, wäre dies dennoch eine Verbesserung.

    10. ol>

      Ich denke, der einzige Grund, warum clientseitiges Hashing dies nicht ist häufig, weil es ungewöhnlich ist. Wann immer es vorgeschlagen wird, fragen sich die Leute, warum es so selten ist, wenn es nur Vorteile gibt. Die Entscheidung, nur serverseitiges Hashing durchzuführen, scheint häufig rationalisiert zu sein. Dies sind einige der Argumente, die ich zuvor gehört habe:

    • "Ein Angreifer würde nur den Code entfernen, der für das Hashing verantwortlich ist!" Dies gilt nur für Webanwendungen. Normale Anwendungen (darunter mobile Anwendungen) haben dieses Problem nicht.
    • "Aber mein Fall gilt für eine Webanwendung!" Wenn clientseitiges Hashing für Webanwendungen üblich wäre, würden wir wahrscheinlich eine Standardisierung sehen (denken Sie an <input type = password hashversion = 1> ), ähnlich wie Sprachen und Frameworks Standard-Hashing-Funktionen für Entwickler verwenden. Wenn ein Feld im Klartext gesendet wird, kann der Browser dies anzeigen. Wir können dies leicht standardisieren, aber nur, wenn Entwickler tatsächlich die Absicht zum Ausdruck bringen und sich dafür entscheiden.
    • "Aber was auch immer das Ergebnis [des clientseitigen Hashs] ist, IST das Passwort!" Wenn Ihre Anmeldedatenbank kompromittiert ist, ist es unwahrscheinlich, dass sich ein Angreifer weiterhin bei Ihrer Anwendung anmelden muss, um alle Daten daraus abzurufen. Die Tiefenverteidigung der meisten Systeme ist wirklich nicht so gut, aber selbst wenn dies der Fall ist, ist das Argument nichtig, da der Rat lautet, einen zusätzlichen schnellen Hash auf dem Server durchzuführen.
    • "Sie sollten es einfach tun Verwenden Sie einen Passwort-Manager, anstatt sich auf die Sicherheit von Hashes zu verlassen! " Ich stimme zu, das wäre ideal. Überall Zwei-Faktor-Authentifizierung, die von allen verwendet wird, mit Passwort-Managern und Smartcards ... Ja, wenn dieser Tag kommt, brauchen wir überhaupt kein Passwort-Hashing mehr. Sie sollten immer noch einen schnellen Hash auf dem Server ausführen, um den oben genannten sekundären Vorteil zu erzielen. Wir können jedoch aufhören, langsame Hashing-Algorithmen und clientseitiges Hashing durchzuführen, da ohnehin niemand Kennwörter wiederverwenden würde.
    • "Sie sollten dies nicht tun der für die Sicherheit zuständige Benutzer! " Sie sind bereits für die Sicherheit zuständig: Sie können jederzeit 123456 als Passwort wählen (oder wenn es dumme Anforderungen gibt, können Sie immer noch "Bailey2009!" Ausführen). Sie können auch die Schlüssel für Ihre TLS-Verbindung veröffentlichen und deren Sicherheit aufheben. Der Benutzer kann immer jede von Ihnen implementierte Sicherheit durcheinander bringen, wenn er möchte.
    • "Aber wie werden Sie den Hash salzen?" Das Feld Benutzername, möglicherweise kombiniert mit einem Domain- oder Firmennamen, um es global eindeutig zu machen. Ein Salz ist nicht geheim, sondern nur einzigartig, genau wie Ihr Benutzername.
    +1, ein paar Punkte: 1) Smartphones begrenzen die Rechenleistung, die Sie für clientseitiges Hashing einsetzen können, wenn Ihre Web- / Mobile-App verwendet werden soll.2) Das Salzen mit dem Benutzernamen ist viel besser als nichts, aber nicht ideal.Benutzernamen sind nicht global eindeutig und ziemlich vorhersehbar.Wahrscheinlich keine große Sache, aber es fühlt sich nicht so gut an.
    Außerdem unterstützt die [Web-Krypto-API] (https://www.w3.org/TR/WebCryptoAPI/#pbkdf2) PBKDF2 und ermöglicht die Verwendung einer nativen (und nicht besonders langsamen) Implementierung, es gibt jedoch (noch) keine Unterstützung.für Argon2 oder Bcrypt.Andererseits läuft diese [bcrypt js-Demo] (https://fpirsch.github.io/twin-bcrypt/) mit asm.js in nur wenigen Sekunden auf meinem Telefon, und das sind ein paar Größenordnungen mehrals eine native Implementierung auf meinem Desktop ist dies möglicherweise noch akzeptabel.Vielleicht haben Hardware- und JS-Verbesserungen es nicht länger zu einem Problem gemacht.
    Vor kurzem gab es einen Fall, in dem ein Unternehmen ein Konto gesperrt hat, weil der Benutzer ein Passwort verwendet hat, das dem Unternehmen nicht gefallen hat, was mich zu dem Problem geführt hat, dass Websites mir das Passwort senden, das ich im Klartext eingebe.Viele Leute argumentieren, dass Client-Hashing nicht notwendig ist, und die meiste Zeit lautet das Argument in der Tat nur "Sei nicht albern! Niemand tut es!"oder ihre Argumente legen lächerliche Einschränkungen auf, wie zum Beispiel, dass Server plötzlich keinen ordnungsgemäßen Kennwortspeicher mehr verwenden, weil sie ihn auf den Client "auslagern"?Lol
    @AndrolGenhald Es ist ein Smartphone. Wenn Sie eine Liga der Legenden spielen können, können Sie eine Zeichenfolge hashen.Ich gehe davon aus, dass die Geräte im Jahr 2019 anständig waren.Das Argument scheint zu sein: "Es ist nicht viel besser, könnte sich genauso gut nicht darum kümmern."


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