Die clientseitige Hashing / Pökeln über HTTPS

Question

Ich frage mich, was die ernsten Probleme mit dem folgenden Setup sind:

Benutzername / Passwort Login Schema Javascript / Ajax fordert das Salz Wert vom Server (wir haben in der vorangegangenen Fragen etablieren Salz ist kein Geheimnis Wert) Javascript Preforms einen SHA1 (oder andere) des Passworts und Salz. Javascript / Ajax zurückkehren den Hash an den Server Der Server wendet ein anderes Salz / Hash-on-top des einen über ajax gesendet.

Transaktionen sind über HTTPS.

Ich bin zu Problemen betroffen, die bestehen können, aber kann mich nicht überzeugen, dass dies so schlecht eines Setup ist. Es sei angenommen, dass alle Benutzer müssen Javascript aktivieren, damit wie jQuery stark auf der Seite verwendet wird. Es ist im Grunde versucht, eine zusätzliche Sicherheitsschicht auf den Klartext eines Passworts hinzuzufügen.

Answer 1

All diese Bemühungen von Salzen und Hashes zwischen dem Client und dem Server zu übergeben bereits in das HTTPS zugrunde liegenden gebaut / SSL-Protokoll. Ich wäre sehr überrascht, wenn eine Sicherheitsschicht in JavaScript ist sehr viel helfen würde. Ich empfehle es einfach und Verwendung Klartext über SSL auf der Client-Seite zu halten. Sorgen über die Verschlüsselung auf der Server-Seite.

Answer 2

Wie immer:. Sehr vorsichtig sein, über die Gestaltung kryptographische Protokolle selbst

Aber das wird gesagt, kann ich den Vorteil, in dem System sehen. Es wird Schutz gegen das Passwort durch ein aufgedeckt wird, Man-in-the-Middle-Angriff und es wird sicherstellen, dass der Server nicht das tatsächliche Kennwort sieht, so etwas im Inneren zu verhindern Anschläge. Auf der anderen Seite bietet es keinen Schutz gegen Man-in-the-Browser, Fischerei etc.

Sie können durch lesen möchten RFC 2617 über HTTP Digest Zugriffsauthentifizierung. Diese Regelung ist ähnlich dem, was Sie vorschlagen.

Answer 3

Das fügt keine zusätzliche Sicherheit. Der JavaScript-Code ist in dem Client, so dass der Hash-Algorithmus bekannt ist. Sie gewinnen nichts von einer clientseitigen Hash in diesem Fall zu tun.

Auch gibt es keinen Grund, warum der Kunde über das Hashing-Salz wissen sollte. Es eigentlich sollte ein geheimer Wert sein, vor allem, wenn Sie dieses Salz verwenden.

Answer 4

Sie gewinnen nichts. Es gibt keinen Grund zu einem Salz, wenn Joe Public durch Anklicken sehen Ansicht> Quelle und die alte Maxime über nie Eingang Client vertrauensvollen gilt doppelt für Passwort-Hashing.

Wenn Sie wirklich die Sicherheit zu erhöhen, verwenden Sie einen SHA-2-basierten Hash (SHA-224/256/384/512), wie SHA-1 mögliche Schwachstellen hat. NIST nicht mehr empfiehlt SHA-1 für Anwendungen, die (wie Passwort-Hashes) zu Kollision Angriffe anfällig sind.

Answer 5

Ich werde zu 100% mit der akzeptierten Antwort nicht einverstanden ist und sage, dass unter keinen Umständen soll ein Original-Passwort jemals überhaupt jemals den Client verlassen. Es sollte immer gesalzen und gehasht werden. Immer, ohne Ausnahme.

Zwei Gründe ... . Der Kunde sollte nicht angewiesen sein, dass alle Server-Komponenten und interne Netzwerke sind TSL. Es ist durchaus üblich für den TSL-Endpunkt ein Load-Balancing-Reverse-Proxy zu sein, die mit App-Servern unter Verwendung von Klartext in Verbindung steht, weil DevOps nicht gestört werden kann Server certs für alle ihre internen Server zu erzeugen.

. Viele Anwender sind geneigt pathologisch ein gemeinsames Passwort für alle ihre Dienste zu nutzen. Die Tatsache, dass ein Server Text-Kennwörter hat, wenn auch nur in Erinnerung, macht es zu einem attraktiven Ziel für Angriffe von außen.