Erfinder des JavaScript-Passwort-Hashing hier

Bereits 1998 habe ich ein Wiki erstellt, die erste Website, die ich mit einem Anmeldesystem erstellt habe. Ich konnte mir kein Hosting mit SSL leisten, aber ich war besorgt über Klartext-Passwörter, die über das Internet gehen. Ich habe über CHAP (Challenge Hash Authentication Protocol) gelesen und festgestellt, dass ich es in JavaScript implementieren kann. Am Ende habe ich JavaScript MD5 als eigenständiges Projekt veröffentlicht und es ist das beliebteste Open Source, das ich entwickelt habe. Das Wiki kam nie über Alpha hinaus.

Im Vergleich zu SSL weist es eine Reihe von Schwächen auf:

• Schützt nur vor passivem Abhören. Ein aktives MITM kann das JavaScript manipulieren und das Hashing deaktivieren.
• Serverseitige Hashes werden zu Kennwortäquivalenten. Zumindest in der gemeinsamen Umsetzung; Es gibt Variationen, die dies vermeiden.
• Erfasste Hashes können brutal erzwungen werden. Es ist theoretisch möglich, dies mit JavaScript RSA zu vermeiden.

Ich habe diese Einschränkungen immer im Vorfeld angegeben. Ich wurde regelmäßig für sie geflammt. Aber ich behalte das ursprüngliche Prinzip bis heute bei: Wenn Sie aus irgendeinem Grund kein SSL haben, ist dies besser als Klartext-Passwörter. In den frühen 2000er Jahren verwendeten einige große Anbieter (insbesondere Yahoo!) dies für Anmeldungen. Sie glaubten, dass SSL selbst nur für Anmeldungen zu viel Overhead haben würde. Ich denke, sie haben 2006 nur für Anmeldungen auf SSL umgestellt, und um 2011, als Firesheep veröffentlicht wurde, haben die meisten Anbieter auf volles SSL umgestellt.

Die kurze Antwort lautet also: clientseitiges Hashing ist selten, weil Benutzer verwenden stattdessen SSL.

Clientseitiges Hashing bietet noch einige potenzielle Vorteile:

• Einige Softwareprogramme wissen nicht, ob es mit bereitgestellt wird SSL oder nicht, daher ist es sinnvoll, Hashing einzuschließen. vBulletin war ein häufiges Beispiel dafür.
• Serverentlastung - Bei rechenintensiven Hashes ist es für den Client sinnvoll, einen Teil der Arbeit zu erledigen. Siehe diese Frage.
• Böswillige Administratoren oder gefährdete Server - Clientseitiges Hashing kann verhindern, dass sie Klartextkennwörter sehen. Dies wird normalerweise verworfen, da sie das JavaScript ändern und das Hashing deaktivieren können. Fairerweise erhöht diese Aktion jedoch die Wahrscheinlichkeit, entdeckt zu werden, und dies hat einige Vorteile.

Obwohl diese Vorteile gering sind und viel Komplexität hinzufügen, besteht ein echtes Risiko dass Sie bei Ihrem Versuch, die Sicherheit zu verbessern, eine schwerwiegendere Sicherheitsanfälligkeit einführen. Und für Leute, die mehr Sicherheit als Passwort wünschen, ist die Multi-Faktor-Authentifizierung eine bessere Lösung.

Die zweite kurze Antwort lautet also: weil die Multi-Faktor-Authentifizierung mehr Sicherheit bietet als das clientseitige Passwort-Hashing .

Um dieses Problem zu verstehen, müssen Sie zuerst verstehen, warum wir Passwörter hashen. Es ist durchaus möglich, ein Passwort im Klartext auf einem Server zu speichern und das übertragene Passwort einfach mit dem empfangenen Passwort zu vergleichen. Solange das Passwort während der Übertragung geschützt ist, ist dies ein sicheres Mittel zur Authentifizierung (gemeinsames Geheimnis).

Der Grund, warum Passwörter gehasht werden, liegt darin, dass das Problem nicht die Authentifizierung, sondern der Speicher ist. Sollte der Server jemals kompromittiert werden, hätte der Angreifer sofort Zugriff auf alle Benutzerkonten, da er nun das zur Authentifizierung der Benutzer verwendete Geheimnis kennt.

Hashing wirkt als Hindernis dafür. Da der Server die zur Authentifizierung tatsächlich erforderlichen Eingaben nicht kennt, gewährt selbst ein Kompromiss mit der Datenbank einem Angreifer keinen Zugriff auf die Benutzerkonten. Sie müssten immer noch die Eingabe herausfinden, um die Hash-Werte zu erreichen, mit denen die Anwendung prüft. Sicher, sie könnten alle Werte in etwas ändern, das sie kennen, aber dies würde schnell Verdacht erregen und das System würde heruntergefahren und gesichert.

Das Problem beim clientseitigen Hashing ist also, dass es das effektiv macht Ergebnis des Hashs ist das Passwort und nicht das Passwort. Nichts hindert einen Angreifer daran, den offiziellen Client zu umgehen und den fertigen Hash einfach direkt an den Server zu senden. Es bietet keinen zusätzlichen (oder Verlust) an Sicherheit während der Authentifizierung, aber in dem Fall, dass Hashing zum Schutz dient, bietet es nichts, da der in der Datenbank gespeicherte Hash tatsächlich das gemeinsame Geheimnis ist, das an den Server übertragen wird.

Das heißt, es gibt zwei bemerkenswerte Dinge, die Ihnen clientseitiges Hashing bietet. Dies trägt zwar nicht zum Schutz Ihres Systems bei, kann jedoch zum Schutz Ihres Benutzers beitragen. Wenn Sie das Kennwort unsicher übertragen oder die Übertragung kompromittiert wird, ohne dass der Clientcode kompromittiert wird, schützen Sie das Kennwort des Benutzers (das auf anderen Websites möglicherweise wiederverwendet wird) weiterhin vor dem Durchsickern.

Das andere ist, dass Sie zusätzliche Iterationen eines Hashs bereitstellen können, um einen Offline-Angriff auf die Datenbank zu erschweren, ohne Serverzyklen verwenden zu müssen (und gleichzeitig die Länge des vom Client übermittelten "Zwischenkennworts" zu verlängern) Sie benötigen noch genügend Serverzyklen, um das verlängerte Kennwort vor einem nicht autorisierten Client zu schützen. Der primäre Schutz, den dies bietet, besteht wiederum darin, zu verhindern, dass das ursprüngliche Kennwort erkannt wird, trägt jedoch nicht zum Schutz des Authentifizierungsmechanismus Ihrer Site bei Aus Sicht des Servers sollte der clientseitige Hash so behandelt werden, als wäre es das direkte Passwort des Benutzers. Es bietet nicht mehr oder nicht weniger Sicherheit auf dem Server , als wenn der Benutzer sein Kennwort direkt angegeben hätte und als solches geschützt werden sollte.

Wenn Sie Um dieses zusätzliche Sicherheitsniveau bieten zu können, würde ich zwei Hashes empfehlen. Hash einmal clientseitig, um ein neues, eindeutiges Passwort zu erstellen, dann Hash dieses Passwort auf dem Server, um einen Wert zu erstellen, den Sie in der DB speichern. Auf diese Weise erhalten Sie das Beste aus beiden Welten.

Zum größten Teil wird SSL ausreichend vertraut, um den Austausch zu schützen, sodass der anfängliche Hash vor der Übertragung als unnötig angesehen wird und ein kompromittierter Server dies jederzeit ändern kann Code, der so an den Client gesendet wird, dass der anfängliche Hash nicht ausgeführt wird. Es ist einfach keine effektive Alternative zu SSL und bietet nicht genügend zusätzlichen Vorteil, um die Kosten und die Komplexität wert zu sein.

Wenn Sie einige Vorteile haben, sollten Sie diese in Ihrer Frage auflisten, damit die Leute herausfinden, ob sie wirklich nützlich sind (und wenn ja, werden Sie vielleicht berühmt;)

Die Leute tun es nicht. t clientseitiges Hashing nicht bevorzugen, da sie bessere Möglichkeiten zum Schutz privater Informationen von Benutzern bieten. Lassen Sie uns über die Orte mit potenziellen Informationslecks nachdenken, von denen es drei gibt:

• Der Client.
• Zwischen dem Client und dem Server.
• Der Server.

Dann wollen wir sehen, warum oder warum nicht clientseitiges Hashing an diesen Stellen hilfreich ist.

• Der Client. P. >

  Wenn auf Ihrem eigenen Computer Malware vorhanden ist, z. B. wenn Ihr Browser kompromittiert ist oder auf Ihrem Computer eine Schlüsselprotokollierungssoftware implantiert ist, verhindert clientseitiges Hashing nicht, dass ein Hacker Ihr Kennwort erhält. Der Grund liegt auf der Hand.

• Zwischen Client und Server.

  Zwischen Client und Server besteht ein Kommunikationskanal. Wenn ein Lauscher auf die Kommunikation wartet, kann das clientseitige Hashing das Durchsickern des Kennworts erschweren, da der Lauscher das ursprüngliche Kennwort aus seinem Hash wiederherstellen muss. Dies ist in der Tat nützlich.

  Diese Sicherheitsanfälligkeit basiert jedoch auf der Voraussetzung eines unsicheren Kommunikationskanals. In Wirklichkeit gibt es Protokolle, deren Existenz versucht, dieses Problem genau zu lösen. Ihre Hauptaufgabe ist es, einen sicheren Kanal über einen unsicheren zu etablieren. Das bekannteste und am weitesten verbreitete Beispiel ist SSL / TLS. Es bietet mehr Funktionalität und bessere Sicherheit als clientseitiges Hashing.

  Die Schlussfolgerung ist, dass clientseitiges Hashing im Kanal hilfreich ist, aber hier sind bessere Tools.

• Der Server.

  Benutzerinformationen können auf dem Server verloren gehen, wenn der Server von einem Hacker kompromittiert wird. Der Hacker kann Benutzerkennwörter aus der Datenbank abrufen, wenn diese im Klartext gespeichert sind. Deshalb machen das heute die meisten Server nicht. Stattdessen speichern sie Hashes von Passwörtern, sodass Hacker die ursprünglichen Passwörter nicht einfach aus ihren vorliegenden Informationen (dh Hashes) wiederherstellen können.

  Sie könnten versucht sein zu glauben, dass die Dinge immer noch gut funktionieren, wenn der Server einfach speichert auf der Clientseite berechnete Hashes. Das ist aber völlig falsch. In dieser Situation werden die Hashes selbst zu Passwortäquivalenten. Der Hacker kann die Authentifizierung bestehen, indem er den Hash einfach übergibt, ohne ihn umzukehren. Das Ziel eines Hackers ist nicht, einen Hash umzukehren, sondern in Ihr Konto einzubrechen. Die Bedeutung liegt im Überprüfungsprozess des Servers für Clientdaten, nicht in der Tatsache, dass die Daten ein Hashwert sind. Daher ist der Vorteil von clientseitigem Hashing hier trivial und der Server muss ohnehin erneut aufbereitet werden.

Zusammenfassend ist clientseitiges Hashing hilfreich Schutz der Benutzerinformationen, der Schutz gilt jedoch weitgehend für den Kommunikationskanal. Da wir dort bessere Ansätze haben (SSL / TLS), ist die Anwendung von clientseitigem Hashing stark unterdrückt. Es ist einfach nicht das beste Werkzeug für die jeweilige Aufgabe.

Es wird empfohlen, auf der Clientseite zu hashen, dann das Kennwort zu salzen und auf der Serverseite erneut zu hashen. Dies ist eine zusätzliche Schutzschicht gegen Menschen bei mittleren Angriffen. SSL ist die erste Schicht, doch Snowdens Enthüllungen machten deutlich, dass SSL von Organisationen wie der NSA relativ einfach kompromittiert werden kann.

Welche Vorteile hätte clientseitiges Passwort-Hashing?

Nun, das Passwort würde nicht im Klartext über das Internet gesendet. Sie sollten jedoch beim Anmelden unbedingt die TLS-Verschlüsselung verwenden, damit das Abhören von Kennwörtern kein Problem darstellt.

Ein weiterer Grund könnte sein, dass der Server niemals sein soll Achten Sie auf das Passwort des Benutzers, auch nicht für eine Mikrosekunde. Das bedeutet, dass Sie dem Server bei der Registrierung den Kennwort-Hash geben und sich dann mit diesem Kennwort-Hash anmelden. Leider löst dies nichts: Das gemeinsame Geheimnis, um sich in das Konto einzuloggen, ist jetzt der Hash, nicht das Passwort. Wenn Sie Kenntnis vom Hash haben, können Sie sich anmelden, ohne das tatsächliche Kennwort zu kennen (da der Server es auch nicht kennt).

Da es sich um eine Webanwendung handelt ...

In einer Datenbank haben wir einen Tabellenaufruf dbo.useracc. Wir speichern dieses Hash-Passwort.

  Benutzerkennwort- ------- ---------- user1 5f4dcc3b5aa765d61d8327deb882cf99user2 202cb962ac59075b964b07152d234b70user3 098f6bcd4621d373cade4e832627b4f6  

und unsere Anmeldefunktion

 code> if (user == $ user und password == $ pass) {return auth.token}  

Angenommen, ein Angreifer hat die Datenbank erfolgreich gehackt und gestohlen und unsere dbo.useracc-Daten gespeichert . Er hat jetzt unser Hash-Passwort.

Wenn Ihr Login-Hash-Prozess im Client gespeichert ist, kann der Angreifer weiterhin mit dem Hash-Passwort auf Ihr Konto zugreifen, indem er einfach die HTTP-POST-Methode anschließt und das zu sendende Passwortfeld ändert Ihr Hash-Passwort und er kann sich weiterhin anmelden. Denken Sie daran, dass Ihre Anwendungsdaten über die POST-Methode mit dem Server kommunizieren, nachdem der Hash überprüft wurde.

Wenn sich der Hashing-Prozess jedoch auf dem Server befindet, ist dies eine andere Geschichte.

  $ pass = md5.hash ($ pass); if (Benutzer == $ Benutzer und Passwort == $ Pass) {return auth.token;}  

Wenn der Hacker das Hash-Passwort zum Anmelden verwendet, handelt es sich um ein Hash-Hash-Passwort, das mit einem Hash-Passwort verglichen wird.

In diesem Fall sagen wir, der Angreifer postet

$ user = user1 $ pass = 5f4dcc3b5aa765d61d8327deb882cf99

Nachdem die Serverseite $ pass = md5.hash (5f4dcc3b5aa765d61d8327deb882cf99) ausgeführt hat ) Es wird '696d29e0940a4957748fe3fc9efd22a3' zurückgegeben, was eine falsche Anweisung zurückgibt.

Hiermit wird ein Angreifer abgewehrt, der die Datenbankdaten erfolgreich gestohlen hat und versucht, über die Webanwendung mit dem Hash-Kennwort darauf zuzugreifen. Und natürlich kann sich der Angreifer immer noch in die Konten hacken, wenn er die Hashes durch Wörterbuchangriffe und so weiter erfolgreich brutal erzwingt / knackt. Der Hacker benötigt jedoch eine längere Zeit, wenn das Kennwort nach einer Kompromittierung des Systems ein gutes Kennwort ist und der Serveradministrator das Kennwort einfach zurücksetzen und den Benutzern eine E-Mail senden kann.

Es wird auch für interne Bedrohungen wie Mitarbeiter in einem verwendet Unternehmen. In einem Unternehmen gibt es Datenbankadministratoren und Entwickler. Sie sind verschiedene Rollen. Um zu verhindern, dass Mitarbeiterbenutzer auf die vertraulichen Daten zugreifen können, müssen sie sowohl auf die Anwendung als auch auf die Datenbank zugreifen können, um auf die Daten zugreifen zu können. Natürlich könnten Sie argumentieren, dass ein DBA die Datenbankdaten immer noch über die Datenbank selbst ändern kann, aber die Entwickler können nicht darauf zugreifen und es ist einfacher festzustellen, woher der Angriff stammt. Es geht um Zugriffssteuerungsrechte und die Minimierung der Risiken und Bedrohungen.

Obwohl das Thema einige konkrete Leckstellen aufweist, wie von @Cyker hervorgehoben, ist die Diskussion hier etwas lebhaft ... Ich möchte einen Punkt hinzufügen, den ich nicht erwähnt habe.

Es ist einfach so, dass Sie, wenn Sie so schnell wie möglich hashen, das Programmierrisiko verringern, wenn Sie versehentlich ein Klartextkennwort an einen Ort übergeben, an den es nicht gehen sollte. Wir ergreifen bereits Maßnahmen wie sichere Zeichenfolgen und sichere Arrays, um zu versuchen, den Klartext so schnell wie möglich zu zerstören. Das Hashing im Moment, in dem Sie das Passwort erhalten, ist eine weitere Maßnahme wie diese ... Während sich der Code weiterentwickelt usw. scheinen die Risiken immer noch verringert zu sein.

Ich habe gerade eine kleine C # "Box" geschrieben, die benötigt wird Der SecureString-Klartext wird sofort gehasht. Auf diese Weise weiß ich einfach, dass er niemals protokolliert oder an eine Bibliothek übergeben wird, die ich nicht erwarte. Hier geht es nicht so sehr um ein Protokoll, sondern nur darum, dass der Programmierer hier sitzt und sich ein Passwort ansieht - ich möchte es nicht anfassen! (In einigen Aspekten ist es immer noch ein Passwortäquivalent, aber es ist zumindest sofort vor Torheit verborgen, wie das Verschieben einer schließenden Klammer in einem verketteten Methodenaufruf und das Übergeben von Klartext an die falsche Stelle. Und ein sicheres Array ist immer noch nicht verborgen.)

Ich werde hier mit dem ausdrücklichen Ziel einspringen, zugunsten des clientseitigen Hashing-Mechanismus abzuwägen. Mal sehen, wie wir davon profitieren:

Client-seitig: Keine Verbesserung.

Während der Übertragung: Schützt das Kennwort bei SSLstrip, bei dem das Kennwort im Klartext übertragen wird. Wenn jedoch HSTS implementiert ist, würden die meisten Leute sagen, dass SSLStrip keine Auswirkungen haben würde. Richtig? Nein.

Beim Eintritt in den Server: Schließlich sehen wir den Hauptvorteil. Was passiert, wenn jemand den Server kompromittiert hat? Sie erhalten einen kontinuierlichen Fluss von Klartextkennwörtern, wenn sie nur Wireshark / TCPDump starten und den privaten Schlüssel des Servers exportieren. Jetzt können sie ein paar Monate am Kabel sitzen und bei Servern mit hohem Volumen (Millionen von Benutzerregistrierungen pro Monat) erhalten sie ihre massive Klartextverletzung. Dies setzt voraus, dass es wertvoller ist, die Kennwörter für die Personen im Dienst abzurufen, als RCE auf ihrem Server zu haben.

Auf dem Server: Leistungsvorteile, wenn er nicht ausgeführt werden muss Verschlüsselung jedes eingehenden Kennworts, wodurch einige Rechenkosten auf den Client verlagert werden, ohne dass neue Sicherheitslücken entstehen. Dies scheint sowohl für den Administrator Ihres Servers als auch für Ihre Hardwarekosten eine gute Sache zu sein.

Es scheint jedoch eine bewährte Methode zu sein, Kennwort-Hashing in die Clientseite zu integrieren, es sei denn, dies führt zu unerträglichen Ladezeiten für Seiten die Benutzer.

Ich stimme zu, dass der Vorteil von clientseitigem Hashing zum Schutz des Authentifizierungsprozesses begrenzt ist, wenn SSL / TLS verfügbar ist. SSL / TLS behebt jedoch nicht die Sicherheitsanfälligkeit für benutzerdefinierte Hardwareangriffe, wenn der Angreifer Zugriff auf die gespeicherten Hashes hat (NACH dem Prozess). Funktionen wie einfache gesalzene Hashes oder Schemata wie PBKDF2 sind aufgrund ihres geringen Speicherbedarfs sehr anfällig für diese Angriffe. Das Knacken von Passwörtern, die mit diesen Schemata geschützt sind, ist billig und schnell. Und das ist mindestens eines der Hauptprobleme beim Passwort-Hashing.

Auf den ersten Blick hat dies nichts mit clientseitigem Hashing im Vergleich zu SSL / TLS zu tun - aber: Wenn ein Server ein speicherfestes implementiert Kennwort-Hashing-Schema wie Scrypt, Argon2 oder Catena zum Schutz benutzerdefinierter Hardwareangriffe erhöhen die Hardwareanforderungen des Servers erheblich. In der Realität reduzieren Dienste daher die Speicherhärte oder wechseln zu anfälligen Schemata. Clientseitiges Hashing hilft ein wenig, dieses Problem zu umgehen. Wenn die Clients diese teuren (speicherintensiven) Funktionen berechnen, kann der Dienst sie verwenden, ohne dass bessere Hardware erforderlich ist.

Moderne Kennwort-Hashing-Schemata bieten daher die Möglichkeit, die teuersten (speicherintensiven) Teile zu delegieren der Funktion an den Client. Diese Funktion heißt Server Relief und wird von Argon2 und Catena angeboten.

Fazit: Die Verwendung moderner Kennwort-Hashing-Schemata, die weniger anfällig für benutzerdefinierte Hardwareangriffe sind, wird die Verwendung von clientseitigem Hashing in Zukunft erhöhen oder zumindest verstärken - natürlich zusammen mit SSL / TLS .

Ich denke, clientseitiger Hash hat einen Vorteil und einen Nachteil:

Pro: Sie verstecken das Passwort im Fall von DNS / Phishing / was auch immer, was für den Benutzer nützlich ist, da die meisten Leute Passwörter wiederverwenden auf mehrere Service. Wie andere Entwickler bereits sagten, dient dies nicht Ihrer eigenen Sicherheit.

Nachteile: Ihr Server erhält das Kennwort nicht, wodurch beispielsweise verhindert wird, dass der Benutzer vor der Kennwortstärke gewarnt wird. Ich weiß, dass einige sagen werden, dass dies clientseitig sein kann / sollte, aber wenn Sie mehrere Clients haben, kann dies hilfreich sein, um serverseitig zu zentralisieren.

Ich denke, die Wahrscheinlichkeit, auf der Clientseite gehackt zu werden, ist höher als auf der Serverseite. (Weil es einige IT-Experten gibt, die sich um den Server kümmern). wenn Ihr Computer bereits gehackt wird. Die clientseitigen Algorithmen, die zum Hashing Ihres Passworts verwendet wurden, können auch von Hackern gestohlen werden. Sobald Ihre Algorithmen kein Geheimnis mehr sind. Ich denke, es wird nutzlos.