Was ist der beste Weg, um das Benutzerpasswort im Client-Browser zu hashen, bevor es an den Webserver gesendet wird, so dass nur der Hash, nicht das Klartext-Passwort erlischt?Password Hashing im Client-Browser
EDIT: unter der Annahme, HTTP verwendet wird (nicht HTTPS)
verwenden Javascript den Hash zu berechnen. Ein Beispiel für die Berechnung von SHA-1-Hashes in JS finden Sie unter this.
Vorsicht, wenn Sie sich von Javascript abhängig machen, wird Ihr System fehlschlagen, sobald jemand JS deaktiviert hat. Sie sollten HTTPS verwenden, wenn Sie Bedenken haben, die eigene Rückschläge haben (z. B. Zertifikate kosten Geld, wenn Sie sofort von den Browsern akzeptiert werden sollen.)
Nicht alle Leute haben JavaScript in ihren Browsern und sogar in den Browsern aktiviert Die Idee, Hashes auf einem Klartext-Kanal zu senden, halte ich für nicht sicher genug.
Ich würde Ihnen empfehlen, eine SSL gesicherte Verbindung in Betracht zu ziehen.
Versuchen Sie mit dieser . Aus Neugier, was ist falsch an der Verwendung von SSL/HTTPS und Verschlüsselung auf der Serverseite?
Ich nehme an, an einfachen HTTP zu arbeiten – Andy
Diese Seite hat recht umfassend Hashing/Krypto stuff: JavaScript Encryption Library
JavaScript Seite Verschlüsselung wie die jQuery Verschlüsselungsbibliothek stoppt Lauscher. MITM (Man-in-the-Middle) kann jedoch immer noch auftreten. SSL/TLS ist die ultimative Wahl, die dringend empfohlen wird, es sei denn, Sie verwenden ein Shared Hosting (keine dedizierten IPs) oder Ihre Site empfängt so viel Datenverkehr, dass Sie nicht einfach alle Verbindungen verschlüsseln können (JS, CSS, HTML, ..). .).
Warum sollten Sie das tun? Effektiv ist der Passwort-Hash zum Passwort geworden und ein Mann in der Mitte, der den Hash abfängt, kann ihn benutzen, um sich als Benutzer zu authentifizieren und Aktionen auszuführen. Auf der anderen Seite, wenn Sie nicht an den Mann in der Mitte glauben, warum senden Sie nicht einfach das Passwort selbst?
Challenge-Response schützt vor Abhören - wo Sie keine Daten ändern können, aber nur zuhören. Da Tokens nur einmalig sind, werden die Lauscher immer zu spät kommen und das Token nicht nutzen. – Tower
Ja, das stimmt, ich nehme an, es würde verhindern, dass ein Angreifer, der nur das Abhören erlaubt, das Passwort entdeckt. Aber in diesem Fall würde ich nur die HTTP-Digest-Authentifizierung verwenden, anstatt meine eigene zu rollen. – erickson
Warum hacken wir Passwörter? Wenn also die Hashes erhalten werden, sind sie schwer zu benutzen.
Was passiert in diesem Modell, wenn die Hashes im System exponiert sind? Der Angreifer sendet sie einfach an den Server und authentifiziert sich als Benutzer.
Aus diesem Grund geschieht das Hashing von Passwörtern immer auf dem Server, nicht auf dem Client!
Ich hoffe, dass Sie planen, den Hash entweder über einen sicheren Kanal zu senden, oder dies ist Teil eines Challenge/Response-Mechanismus. Ansonsten ist dies nicht sicherer als das Senden des Passworts selbst im Klartext ... –
@Roger Lipscombe, diese Methode kann für den Benutzer tatsächlich eine leichte Verbesserung darstellen. Selbst wenn kein sicherer Kanal verfügbar ist (nur SSL würde funktionieren, keine JS-Alternative wäre kugelsicher), würde es zumindest den Hash für die Site eindeutig machen. Um den Hash eindeutig zu machen, * muss er natürlich gesalzen werden *. – Inshallah
Zugegeben, dass es den Hash für die Site eindeutig machen würde - nützlich, wenn der Benutzer dasselbe Passwort auf mehreren Sites verwendet; verhindert nicht die Wiederholung auf derselben Website. Und, wenn der Hash gesalzen ist, dann muss entweder das Salz vom Client zum Server gehen - nicht sicherer als zuvor; oder andersherum, in diesem Fall ist es eine Herausforderung/Antwort. –