it-swarm.com.de

Warum ist das clientseitige Hashing eines Passworts so ungewöhnlich?

Es gibt nur sehr wenige Websites, die das Benutzerkennwort hashen, bevor sie es an den Server senden. Javascript unterstützt nicht einmal SHA oder andere Algorithmen).

Ich kann mir jedoch einige Vorteile vorstellen, wie den Schutz vor Cross-Site-Lecks oder böswilligen Administratoren, die SSL nicht bietet.

Warum ist diese Praxis auf Websites so ungewöhnlich?

86
Muis

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 auch nur für Anmeldungen zu viel Overhead haben würde. Ich denke, sie haben 2006 nur für Logins 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, da stattdessen SSL verwendet wird.

Es gibt noch einige potenzielle Vorteile von clientseitigem Hashing:

  • Einige Softwareprogramme wissen nicht, ob sie mit SSL bereitgestellt werden oder nicht. Daher ist es sinnvoll, Hashing einzuschließen. vBulletin war ein häufiges Beispiel dafür.
  • Serverentlastung - Mit 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 einen gewissen Wert.

Obwohl diese Vorteile gering sind und viel Komplexität verursachen, besteht letztendlich das Risiko, dass Sie bei Ihrem Versuch, die Sicherheit zu verbessern, eine schwerwiegendere Sicherheitslücke einführen. Und für Menschen, die mehr Sicherheit als Passwort wünschen, ist die Multi-Faktor-Authentifizierung eine bessere Lösung.

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

52
paj28

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 Barriere 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, anhand derer 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 besteht also darin, dass das Ergebnis des Hashs effektiv zum Kennwort und nicht zum Kennwort wird. 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 clientseitiges Hashing Ihnen bietet. Es hilft zwar überhaupt nicht, Ihr System zu schützen, aber es kann helfen, Ihren Benutzer zu schützen. 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), das Sie jedoch weiterhin benötigen Ausreichende 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.

Anders ausgedrückt, obwohl es aus Sicht des Servers einige geringfügige Schutzmaßnahmen bietet, sollte der clientseitige Hash so behandelt werden, als wäre er das direkte Kennwort des Benutzers. Es bietet nicht mehr oder nicht weniger Sicherheit auf dem Server als wenn der Benutzer sein Passwort direkt angegeben hätte und als solches geschützt werden sollte.

Wenn Sie diese zusätzliche Sicherheitsstufe bereitstellen möchten, 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 gefährdeter Server den an den Client gesendeten Code jederzeit so ändern kann, 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.

47
AJ Henderson

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 bevorzugen kein clientseitiges Hashing, weil sie die privaten Informationen der Benutzer besser schützen können. Lassen Sie uns über die Orte mit potenziellen Informationslecks nachdenken, und es gibt drei davon:

  • Der Kunde.
  • Zwischen Client und Server.
  • Der Kellner.

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

  • Der Kunde.

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

  • Zwischen Client und Server.

    Es gibt den Kommunikationskanal zwischen Client und Server. 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. Es ist in der Tat nützlich hier.

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

    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, so dass Hacker die ursprünglichen Passwörter nicht einfach aus ihren vorliegenden Informationen (d. H. Hashes) wiederherstellen können.

    Sie könnten versucht sein zu glauben, dass die Dinge immer noch gut funktionieren, wenn der Server einfach auf der Clientseite berechnete Hashes speichert. Das ist aber völlig falsch. In dieser Situation werden die Hashes selbst zu Passwortäquivalenten. Der Hacker kann die Authentifizierung durch einfaches Übergeben des Hashs ohne Umkehrung übergeben. 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 clientseitig Hashing hier trivial und der Server muss trotzdem erneut aufbereitet werden.

Zusammenfassend lässt sich sagen, dass clientseitiges Hashing beim Schutz von Benutzerinformationen hilfreich ist, der Schutz jedoch weitgehend für den Kommunikationskanal gilt. 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.

22
Cyker

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 Passwörtern kein Problem darstellt.

Ein weiterer Grund könnte sein, dass Sie nicht möchten, dass der Server jemals das Kennwort des Benutzers kennt, 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 erhalten, können Sie sich anmelden, ohne das tatsächliche Kennwort zu kennen (da der Server es auch nicht kennt).

6
Philipp

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, aber Snowdens Enthüllungen haben deutlich gemacht, dass SSL von Organisationen wie dem NSA) relativ leicht kompromittiert werden kann.

6
Mayhem Software

Da Sie über Webanwendung sprechen ...

In einer Datenbank haben wir einen Tabellenaufruf dbo.useracc, in dem wir dieses Hash-Passwort speichern

User        Password
--------       ----------
user1       5f4dcc3b5aa765d61d8327deb882cf99
user2       202cb962ac59075b964b07152d234b70
user3       098f6bcd4621d373cade4e832627b4f6

und unsere Login-Funktion in der Webanwendung ist so etwas wie

if (user == $user and password == $pass) {
           return auth.token
}

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

Wenn Ihr Anmelde-Hashes-Prozess im Client gespeichert ist, kann der Angreifer weiterhin mit dem Hash-Passwort auf Ihr Konto zugreifen, indem er einfach die HTTP POST -Methode, die das Passwortfeld ändert, um Ihr Hash-Passwort und ihn zu senden) verbindet Es ist weiterhin möglich, sich anzumelden. Denken Sie daran, dass Ihre Anwendungsdaten über die Methode POST) 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 (user == $user and password == $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 den Angreiferbeitrag

$ user = user1 $ pass = 5f4dcc3b5aa765d61d8327deb882cf99

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

Dies dient dazu, Angreifer abzuwehren, die die Datenbankdaten erfolgreich gestohlen haben und versuchen, ü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 Unternehmen verwendet. 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 weiterhin ü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.

3
Sky

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 einen Hash erstellen, das Programmierrisiko verringern, wenn Sie versehentlich ein Klartextkennwort an einen Ort übergeben, an dem es nicht gespeichert werden 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 in dem 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 den SecureString-Klartext aufnimmt und sofort hasht - 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.)

3
Steven Coco

Ich werde hier mit dem ausdrücklichen Ziel einspringen, zugunsten des clientseitigen Hashing-Mechanismus abzuwägen. Mal sehen, wie uns das nützt:

Client-Seite: Keine Verbesserung.

Unterwegs: Schützt das Passwort bei SSLstrip, bei dem das Passwort im Klartext übertragen wird. Wenn jedoch HSTS implementiert ist, würden die meisten Leute sagen, dass SSLStrip keine Auswirkungen haben würde. Recht? Nr.

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) kommt es zu einer massiven Verletzung des Klartextes. Dies setzt voraus, dass es natürlich wertvoller ist, die Kennwörter für die Personen im Dienst abzurufen, als RCE auf ihrem Server zu haben.

Auf dem Server: Leistungsvorteile, wenn nicht bei jedem eingehenden Kennwort bcrypt ausgeführt werden muss, 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 sieht jedoch so aus, als würde die beste Vorgehensweise darin bestehen, Kennwort-Hashing in die Clientseite zu integrieren, es sei denn, dies führt zu unerträglichen Ladezeiten für die Benutzer.

1
DeepS1X

Ich bin damit einverstanden, 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 Kennwort-Hashing-Schema wie Scrypt, Argon2 oder Catena implementiert, um benutzerdefinierte Hardwareangriffe zu schützen, die Hardware des Servers Die Anforderungen steigen dramatisch. 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 Passwort-Hashing-Schemata bieten daher die Möglichkeit, die teuersten (speicherintensiven) Teile der Funktion an den Client zu delegieren. Diese Funktion heißt Server Relief und wird von Argon2 und Catena angeboten.

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

1
BeloumiX