it-swarm-eu.dev

Was soll übertragen werden? Passwort oder sein Hash?

Nehmen wir an, ich speichere in meiner Datenbank mit Salt gehashte Passwörter mit einem ziemlich teuren Hash (Verschlüsselung, 1000 Runden SHA2, was auch immer).

Was soll ich beim Anmelden über das Netzwerk übertragen und warum? Passwort oder sein Hash?

Ist es möglich, eine solche Anmeldung über einen unverschlüsselten Kanal wie HTTP zu schützen?

40
Konrad Garus

Wenn Sie den Hash vom Client übertragen, bietet dies keinen Sicherheitsvorteil und macht den Hash sinnlos:
Wenn sich ein Benutzer anmelden kann, indem er den Hash an den Server sendet, ist Hash effektiv das Passwort.

61
AviD

Wenn es bei Ihrem Authentifizierungsprotokoll darum geht, ein Kennwort oder einen Hash des Kennworts mit einfachem HTTP an den Server zu senden, ist dies aus zwei Gründen von Natur aus sehr schwach:

  • Jemand, der die Leitung ausspioniert, könnte aufzeichnen, was der Client sendet. Wenn nur das Senden dieser Bytes Zugriff gewährt, kann der Angreifer sie einfach erneut senden. Das ist ein Wiederholungsangriff . Auf dieses Problem spielt @AviD in seiner Antwort an. Keine Menge Hashing wird das beheben. Einige Protokolle versuchen, dieses Problem zu beheben, indem sie eine "Herausforderung" vom Server einfügen (ein zufälliger Wert, der für jede Verbindung neu erstellt wird), der zusammen mit dem Kennwort auf dem Client gehasht wird. Darum geht es bei HTTP Digest-Authentifizierung .

  • Selbst wenn die Authentifizierung funktioniert hat, handelt es sich immer noch um einfaches HTTP. Alle Daten, die gesendet werden danach, sind daher anfällig für Abhören und Änderungen durch Angreifer. Wenn das Transportmedium ungeschützt ist, wird durch die Authentifizierung nur der unkomplizierteste Angreifer abgeschreckt. Hier schlägt HTTP Digest fehl.

Daher benötigen Sie wirklich SSL (auch bekannt als HTTPS), um nicht nur das Kennwort oder den Hash davon zu übermitteln, sondern auch den Rest der Konversation zwischen Client und Server .


Ich gehe im Folgenden davon aus, dass das Protokoll in einem SSL-Tunnel ausgeführt wird. Sie haben Recht, einen langsamen Hash wie bcrypt oder PBKDF2 verwenden zu wollen; Beachten Sie, dass auch ein salt erforderlich ist, um eine Kostenteilung zu verhindern (z. B. vorberechnete Tabellen). Langsames, gesalzenes Hashing wird verwendet, um die intrinsische Schwäche von Passwörtern zu bewältigen. Jetzt möchten Sie möglicherweise einen Teil des Hashing-Aufwands auf dem Client auslagern. Dies kann funktioniert, wirft jedoch einige praktische Fragen auf:

  • Da die Kennwortverarbeitung ein Salt enthalten muss, ein neues für jede Kennwortinstanz, muss das Salt an den Client übermittelt werden, damit der Client es in das von ihm durchgeführte Hashing einbeziehen kann. Dies erhöht die Protokollkomplexität: Der Client muss zuerst den Benutzernamen an den Server senden, dann muss der Server das Salt zurücksenden, und (nur dann) kann der Client beginnen, das Kennwort zu hashen. Dies ist eine weitere Netzwerk-Rundreise als mit der üblichen "Benutzername und Passwort als eine senden POST Anfrage").

  • Beim langsamen Hashing wird akzeptiert, dass für jedes Kennwort viel CPU ausgegeben werden muss, sodass der Angreifer auch für jedes Kennwort viel CPU ausgeben muss. Wenn sich die verbrauchte CPU jedoch auf dem Client befindet, können wir sie nicht so oft erhöhen, wie wir möchten, weil: 1) es Clients gibt, die sehr wenig CPU haben (z. B. einige billige Smartphones oder Tablets), und 2) der Webkontext dies impliziert Die Verwendung von Javascript und die Leistung von Javascript ist beim Hashing sehr schlecht (sagen wir mindestens 20 Mal langsamer als C-Code).

Daher ist die übliche Weisheit, dass es sich nicht lohnt, einen Teil des Passwort-Hashing auf dem Client durchzuführen.

24
Thomas Pornin

Beide Optionen sind unsicher.

Durch die Übertragung des Passworts wird Ihr Protokoll im Klartext angezeigt. Wenn Sie den Hash übertragen, sind Sie anfällig für Wiederholungsangriffe.

APOP ist eine Login-Implementierung für das POP-Protokoll. Dadurch kann das Protokoll das Kennwort für alle Listener im Netzwerk geheim halten. Ein Nachteil dabei ist, dass sowohl der Client als auch der Server das Kennwort im Klartext kennen müssen, da dies das gemeinsame Geheimnis ist. Vor dem Protokoll haben sowohl der Client als auch der Server <Kennwort>. Die Protokollkommunikation ist im Wesentlichen wie folgt:

  1. Der Client stellt eine Verbindung zum Server her und sendet ein zufälliges Token (T1).
  2. Server sendet ein zufälliges Token (T2)
  3. Client sendet M = sha (T1 + T2 + <Passwort: Client-Kopie>) an den Server
  4. Der Server prüft, ob sha (T1 + T2 + <Passwort: Serverkopie>) mit M übereinstimmt (der gerade empfangene Hash).

Hier kennt der Server sowohl die Magie als auch das Kennwort und kann feststellen, ob der Benutzer das richtige Kennwort kennt, ohne es Hörern auszusetzen.

Die beste Vorgehensweise wäre, die Hashes sicher in der Datenbank zu speichern und sich auf verschlüsselte Kanäle zu verlassen.

4