it-swarm.com.de

Sollte ich das Passwort hashen, bevor ich es an den Server sende?

Mir ist aufgefallen, dass die meisten Sites die Passwörter als Klartext über HTTPS an den Server senden. Gibt es einen Vorteil, wenn ich stattdessen den Hash des Passworts an den Server gesendet habe? Wäre es sicherer?

94
Jader Dias

Dies ist eine alte Frage, aber ich hatte das Bedürfnis, meine Meinung zu dieser wichtigen Angelegenheit zu äußern. Hier gibt es so viele Fehlinformationen

Das OP hat nie erwähnt, dass das Passwort in Klartext über HTTP gesendet wird - nur HTTPS, aber viele scheinen aus irgendeinem Grund auf die Frage zu antworten, ein Passwort über HTTP zu senden. Das gesagt:

Ich glaube, Passwörter sollten niemals im Klartext aufbewahrt (geschweige denn übertragen) werden. Das heißt, nicht auf der Festplatte oder sogar im Speicher.

Die Leute, die hier antworten, scheinen zu glauben, HTTPS sei eine Silberkugel, was es nicht ist. Es hilft jedoch sehr und sollte in jeder authentifizierten Sitzung verwendet werden.

Es ist wirklich nicht erforderlich, zu wissen, was ein Originalkennwort ist. Alles, was erforderlich ist, ist eine zuverlässige Möglichkeit, eine Authentifizierung zu generieren (und diese zuverlässig erneut zu generieren) "Schlüssel" basiert auf dem vom Benutzer gewählten Originaltext. In einer idealen Welt sollte dieser Text sofort einen "Schlüssel" erzeugen, indem er mit irreversiblem Salz gehasht wird. Dieses Salt sollte für die zu generierenden Benutzeranmeldeinformationen eindeutig sein. Dieser "Schlüssel" wird von Ihren Systemen als Kennwort verwendet. Auf diese Weise sind diese Anmeldeinformationen nur für Ihre eigene Organisation von Nutzen, wenn Ihre Systeme in Zukunft kompromittiert werden, und nirgendwo sonst, wo der Benutzer faul war und dasselbe Kennwort verwendet hat.

Wir haben also einen Schlüssel. Jetzt müssen wir alle Spuren des Kennworts auf dem Clientgerät bereinigen.

Als nächstes müssen wir den Schlüssel für Ihre Systeme bekommen. Sie sollten niemals einen Schlüssel oder ein Passwort "im Klartext" übermitteln. Nicht einmal über HTTPS. HTTPS ist nicht undurchdringlich. Tatsächlich können viele Unternehmen zu vertrauenswürdigen MITM werden - nicht aus Angriffssicht, sondern um den Datenverkehr zu überprüfen und ihre eigenen Sicherheitsrichtlinien umzusetzen. Dies schwächt HTTPS und ist nicht die einzige Möglichkeit, wie sie auftritt (z. B. Weiterleitungen zu HTTP MITM-Angriffen). Niemals davon ausgehen, dass es sicher ist.

Um dies zu umgehen, haben wir den Schlüssel mit einem einmaligen Nonce versehen. Diese Nonce ist für jede Übermittlung eines Schlüssels an Ihre Systeme eindeutig - auch für denselben Berechtigungsnachweis während derselben Sitzung, wenn Sie ihn mehrmals senden müssen. Sie können diesen Fehler rückgängig machen, sobald er in Ihren eigenen Systemen eintrifft, um den Authentifizierungsschlüssel wiederherzustellen und die Anforderung zu authentifizieren.

An diesem Punkt würde ich es ein letztes Mal irreversibel hacken, bevor es dauerhaft in Ihren eigenen Systemen gespeichert wird. Auf diese Weise können Sie das Salt des Berechtigungsnachweises für SSO- und ähnliche Zwecke an Partnerorganisationen weitergeben, während Sie nachweisen können, dass Ihre eigene Organisation nicht die Identität des Benutzers annehmen kann. Das Beste an diesem Ansatz ist, dass Sie niemals etwas freigeben, das vom Benutzer ohne dessen Berechtigung generiert wurde.

Machen Sie mehr Nachforschungen, denn es steckt mehr dahinter, als ich selbst verraten habe. Wenn Sie Ihren Benutzern jedoch echte Sicherheit bieten möchten, ist diese Methode meines Erachtens derzeit die vollständigste Antwort.

TL; DR:

Verwenden Sie HTTPS. Sicheres Hashing von Passwörtern, irreversibel, mit einem eindeutigen Salt pro Passwort. Tun Sie dies auf dem Client - übertragen Sie nicht das eigentliche Passwort. Das Senden des ursprünglichen Benutzerpassworts an Ihre Server ist niemals "OK" oder "Fein". Bereinigen Sie alle Spuren des ursprünglichen Kennworts. Verwenden Sie ein nonce unabhängig von HTTP/HTTPS. Es ist auf vielen Ebenen viel sicherer. (Antwort an OP).

142
user3299591

Da es über HTTPS läuft, ist es definitiv in Ordnung, das Passwort ohne Hashing zu senden (über HTTPS ist es kein Klartext). Wenn Ihre Anwendung auf HTTPS angewiesen ist, um den Inhalt zu schützen, ist es außerdem sinnlos, das Kennwort vor dem Senden über HTTPS zu hacken (d. H., Wenn ein Angreifer die Daten auf der Leitung entschlüsseln kann, sind Sie sowieso geschraubt).

23
Kiersten Arnold

Nein, in der Tat wäre dies eine Sicherheitslücke. Wenn der Angreifer in der Lage ist, den Hash aus der Datenbank abzurufen, kann er ihn zur Authentifizierung verwenden, ohne ihn knacken zu müssen. Ein Benutzer oder Angreifer sollte unter keinen Umständen in der Lage sein, ein Hash-Passwort zu erhalten.

Der Sinn des Hashens von Passwörtern besteht darin, eine zusätzliche Sicherheitsebene hinzuzufügen. Wenn ein Angreifer in der Lage ist, den Hash und Salt mithilfe von SQL Injection oder einer unsicheren Sicherung aus der Datenbank abzurufen, muss er den Klartext finden, indem er ihn brutal erzwingt. John The Ripper wird häufig verwendet, um gesalzene Passwort-Hashes zu knacken.

Die Nichtverwendung von https verstößt gegen die OWASP Top 10: A9-Ungenügender Schutz der Transportschicht

EDIT: Wenn Sie in Ihrer Implementierung einen sha256(client_salt+plain_text_password) und dann einen anderen Hash auf der Serverseite sha256(server_salt+client_hash) berechnen dann ist dies keine ernsthafte Sicherheitsanfälligkeit. Es besteht jedoch weiterhin die Gefahr, dass die Anforderung abgehört und wiedergegeben wird. Dies ist also immer noch ein klarer Verstoß gegen WASP A9. Hierbei wird jedoch immer noch ein Message Digest als Sicherheitsebene verwendet.

Das nächste, was ich bei einem clientseitigen Ersatz für https gesehen habe, ist ein diffie-hellman beim Schlüsselaustausch in Javascript . Dies verhindert jedoch aktive MITM-Angriffe und ist somit bis auf weiteres ein Verstoß gegen OWASP A9. Die Autoren des Codes sind sich einig, dass dies kein vollständiger Ersatz für HTTPS ist, jedoch besser als nichts und besser als ein clientseitiges Hashing-System.

17
rook

Das Senden eines Hashs über die Leitung macht den Zweck des Hashs völlig zunichte, da ein Angreifer den Hash einfach senden und das Passwort vergessen kann. Kurz gesagt, ein System, das die Authentifizierung mit einem Hash im Klartext vornimmt, ist weit offen und kann nur durch Netzwerk-Sniffing gefährdet werden.

8
Paul Keister

Das Passwort im Klartext zeigt nie (auch nicht bei Verwendung von HTTPS) den Client verlassen. Es sollte irreversibel gehasht werden, bevor der Client verlassen wird, da der Server das tatsächliche Kennwort nicht kennen muss.

Durch Hashing und anschließende Übertragung werden Sicherheitsprobleme für faule Benutzer behoben, die dasselbe Kennwort an mehreren Standorten verwenden (ich weiß, dass ich es tue). Dies schützt jedoch nicht Ihre Anwendung als Hacker, der Zugriff auf die Datenbank erlangt hat (oder auf andere Weise den Hash in die Hände bekommen hat), da der Hacker den Hash nur übertragen und ihn vom Server akzeptieren lassen könnte.

Um dieses Problem zu lösen, können Sie natürlich den Hash, den der Server empfängt, einfach hashen und ihn einen Tag lang aufrufen.

Mein Ansatz für das Problem in einer Socket-basierten Webanwendung, die ich erstelle, ist, dass der Server beim Herstellen einer Verbindung zum Client ein Salt generiert (eine zufällige Zeichenfolge, die vor dem Hashing hinzugefügt wird) und diese in der Sockets-Variablen speichert. Anschließend überträgt er diesen Hash an den Client. Der Client nimmt das Benutzerpasswort, hascht es, fügt das Salt vom Server hinzu und hascht das Ganze, bevor er es an den Server überträgt. Dann wird es an den Server gesendet, der diesen Hash mit dem Hash vergleicht (Hash im DB + Salt). Soweit ich weiß, ist dies ein guter Ansatz, aber um fair zu sein, habe ich nicht viel über das Thema gelesen und wenn ich mich in irgendetwas irre, würde ich gerne korrigiert werden :)

6
Victor Zimmer

Wenn Sie ein Klartextkennwort über HTTPS durch ein Hashkennwort über HTTP ersetzen möchten, fragen Sie nach Problemen. HTTPS generiert beim Öffnen eines Kommunikationskanals einen zufälligen, gemeinsam genutzten Transaktionsschlüssel. Das ist schwer zu knacken, da Sie sich so ziemlich darauf beschränken, den für eine (relativ) kurzfristige Transaktion verwendeten gemeinsamen Schlüssel zu erzwingen. Während Ihr Hasch nur beschnüffelt, offline genommen und in einem Rainbow-Tisch nachgeschlagen werden kann oder einfach nur über einen langen Zeitraum gezwungen wird.

Eine grundlegende clientseitige Kennwortverschleierung (kein Hash), die über HTTPS gesendet wird, hat jedoch einen gewissen Wert. Wenn ich mich nicht irre, wird diese Technik tatsächlich von einigen Banken verwendet. Der Zweck dieser Technik besteht nicht darin, das Kennwort vor dem Schnüffeln über den Draht zu schützen. Es geht vielmehr darum, zu verhindern, dass das Kennwort für blöde Spionagetools und Browser-Plug-Ins verwendet werden kann, die nur jede angezeigte HTTPS-GET/POST-Anforderung abfangen. Ich habe eine Protokolldatei gesehen, die von einer böswilligen Website mit 400 MB zufälliger GET/POST-Transaktionen aus Benutzersitzungen erfasst wurde. Sie können sich vorstellen, dass Websites, die nur HTTPS verwendeten, mit Klartextkennwörtern im Protokoll angezeigt werden, Websites mit sehr einfacher Verschleierung (ROT13) jedoch auch mit Kennwörtern, die nicht sofort verwendet werden.

Verwenden Sie HTTP Digest - es sichert das Passwort sogar über http (aber die beste Verwendung wäre http Digest über https)

Wikipedia:

Die HTTP-Digest-Zugriffsauthentifizierung ist eine der vereinbarten Methoden, die ein Webserver verwenden kann, um Anmeldeinformationen mit einem Webbenutzer auszuhandeln (unter Verwendung des HTTP-Protokolls). Die Digestauthentifizierung soll die unverschlüsselte Verwendung der Standardzugriffsauthentifizierung ersetzen, sodass die Benutzeridentität sicher hergestellt werden kann, ohne dass ein Kennwort im Klartext über das Netzwerk gesendet werden muss. Digest-Authentifizierung ist im Grunde eine Anwendung von MD5-Verschlüsselungs-Hashing unter Verwendung von Nonce-Werten, um eine Kryptoanalyse zu verhindern.

Link: http://en.wikipedia.org/wiki/Digest_access_authentication

Wenn Sie eine "echte" Verwendung sehen möchten, können Sie sich phpMyID anschauen - einen PHP-OpenID-Anbieter, der die http-Digest-Authentifizierung verwendet http://siege.org/phpmyid.php

.. oder Sie können mit den PHP-Auth-Beispielen unter http://php.net/manual/en/features.http-auth.php beginnen

HTTP-Digest rfc: http://www.faqs.org/rfcs/rfc2617

Nach meinen Tests unterstützen es alle modernen Browser ...

2
vlad b.

Haftungsausschluss: Ich bin auf jeden Fall ein Sicherheitsexperte - und ich poste mit der Hoffnung , dass andere meine Position als übervorsichtig oder verbesserungsfähig kritisieren und ich daraus lernen werde. Vor diesem Hintergrund möchte ich nur betonen, dass Hashing, wenn es Ihren Client verlässt, nicht bedeutet, dass Sie kein Hashing auf dem Backend ausführen müssen, bevor Sie es in die Datenbank stellen.

Beides machen

Beides, weil:

  1. Durch das Hashing auf der Überfahrt werden Schwachstellen des Transports abgedeckt. Wenn die SSL-Verbindung beeinträchtigt ist, können sie das unformatierte Kennwort immer noch nicht sehen. Es spielt keine Rolle, ob Sie sich als autorisierte Benutzer ausgeben können, aber es schützt Ihre Benutzer davor, dass ihre Passwörter in Verbindung mit ihrer E-Mail gelesen werden. Die meisten Benutzer befolgen nicht die bewährten Methoden und verwenden für viele ihrer Konten dasselbe Kennwort. Dies kann eine ernsthafte Sicherheitsanfälligkeit für Ihre Besucher darstellen.

  2. Wenn jemand irgendwie in der Lage war, Passwörter aus der Datenbank zu lesen (dies geschieht, denken Sie an SQL-Injection), kann er dennoch keine privilegierten Aktionen ausführen, die die Identität von Benutzern über meine API vortäuschen. Dies liegt an der Hash-Asymmetrie. Selbst wenn sie den in Ihrer Datenbank gespeicherten Hash kennen, wissen sie nicht, mit welchem ​​Originalschlüssel er erstellt wurde, und anhand dessen authentifiziert sich Ihre Authentifizierungs-Middleware. Dies ist auch der Grund, warum Sie Ihren Hash-Speicher immer salzen sollten.

Zugegeben, sie könnten eine Menge anderen Schadens anrichten, wenn sie die Freiheit hätten, zu lesen, was sie von Ihrer Datenbank wollen.

Ich möchte hier nur betonen, dass, wenn Sie sich dazu entschließen, den Schlüssel vor der Abreise von Ihren Kunden zu hacken, dies nicht ausreicht - das Back-End-Hashing ist viel wichtiger, und aus diesem Grund: Wenn jemand den Datenverkehr von Ihnen abfängt Client, dann sehen sie den Inhalt des Feldes password. Ob es sich um einen Hash oder um einfachen Text handelt, spielt keine Rolle - sie können ihn wörtlich kopieren, um sich als autorisierter Client auszugeben. (Es sei denn, Sie befolgen die Schritte, die @ user3299591 umreißt, und ich empfehle Ihnen, dies zu tun). Das Hashing der DB-Spalte ist dagegen eine Notwendigkeit und überhaupt nicht schwer zu implementieren.

2
pixelpax

Wenn Sie mit einem https-Server verbunden sind, sollte der Datenstrom zwischen Server und Browser verschlüsselt sein. Die Daten sind nur Klartext vor dem Versand und nach dem Empfang. Wikipedia-Artikel

1
jac

Ersetzt SSL/TLS nicht das Nonce? Ich sehe keinen Mehrwert davon, da SSL/TLS auch vor Wiederholungsangriffen schützt.

Ref. https://en.wikipedia.org/wiki/Cryptographic_nonce

0
Tom Kip

Es wäre tatsächlich weniger sicher, das Passwort zu hacken und es über einen unverschlüsselten Kanal zu senden. Sie werden Ihren Hashing-Algorithmus auf dem Client verfügbar machen. Hacker könnten einfach den Hash des Passworts abfangen und es später zum Einhacken verwenden.

Durch die Verwendung von HTTPS verhindern Sie, dass ein Hacker das Kennwort von einer einzigen Quelle erhält, da HTTPS zwei Kanäle verwendet, die beide verschlüsselt sind.

0
Carter Medlin