it-swarm-eu.dev

Warum fast keine Webseiten Passwörter im Client hashen, bevor sie gesendet (und erneut auf dem Server gehasht) werden, um sie vor der Wiederverwendung von Passwörtern zu "schützen"?

Es gibt viele Websites im Internet, für die Anmeldeinformationen erforderlich sind. Der einzige Schutz vor der Wiederverwendung von Kennwörtern ist das "Versprechen", dass die Kennwörter auf dem Server gehasht werden, was nicht immer der Fall ist.

Ich frage mich also, wie schwierig es ist, eine Webseite zu erstellen, auf der Kennwörter auf dem Clientcomputer (mit Javascript) gehasht werden, bevor sie an den Server gesendet werden, wo sie erneut gehasht werden. Theoretisch bietet dies keine zusätzliche Sicherheit, in der Praxis kann dies jedoch zum Schutz vor "betrügerischen Websites" verwendet werden, die Ihr Kennwort nicht auf dem Server hashen.

46
Martín Fixman

Warum wird es nicht verwendet? Weil es viel zusätzliche Arbeit für null Gewinn ist. Ein solches System wäre nicht sicherer. Es könnte sogar weniger sicher sein, da es den falschen Eindruck erweckt, sicherer zu sein, was dazu führt, dass Benutzer weniger sichere Praktiken anwenden (wie die Wiederverwendung von Passwörtern, Wörterbuchkennwörter usw.).

46
Rein Henrichs

Theoretisch bietet dies keine zusätzliche Sicherheit, in der Praxis kann dies jedoch zum Schutz vor "betrügerischen Websites" verwendet werden, die Ihr Kennwort nicht auf dem Server hashen.

Wie genau schützt dich das? Es hört sich so an, als ob Sie nur das Hash-Passwort hashen möchten, was irgendwie sinnlos ist. Denn das Hash-Passwort würde dann zum Passwort.

Es gibt viele Websites im Internet, für die Anmeldeinformationen erforderlich sind. Der einzige Schutz vor der Wiederverwendung von Kennwörtern ist das "Versprechen", dass die Kennwörter auf dem Server gehasht werden, was nicht immer der Fall ist.

Wie wäre es, wenn Sie nicht dasselbe Passwort für mehr als eine Site verwenden? Der Grund, warum Websites das Passwort theoretisch hashen, besteht darin, den Zugriff auf Ihr Konto zu verhindern, wenn SIE kompromittiert werden. Es ist einfach dumm, dasselbe Passwort für mehrere Websites zu verwenden.

Wenn Sie Javascript verwendet hätten, müsste der "Hacker" nur dieselbe Methode für die Hash-Hash-Passwörter verwenden. Sobald Sie die Hash-Informationen haben, ist es nur noch eine Zeit, um das Passwort zu berechnen -> denselben Hash in der Datenbank, der den Zugriff auf ein Konto verhindert.

14
Ramhound

Weil es wenig bis gar keinen Wert hinzufügen würde. Der Grund für das Hashing ist, dass der Hacker, wenn Ihre Datenbank gehackt wird, keine Liste gültiger Kennwörter hat, sondern nur Hashes. Daher konnten sie sich nicht als Benutzer ausgeben. Ihr System kennt das Passwort nicht.

Sicher kommt von SSL-Zertifikaten und irgendeiner Form der Authentifizierung. Ich möchte, dass meine Benutzer ein Passwort angeben, damit ich den Hash daraus berechnen kann.

Außerdem würde sich der Hashing-Algorithmus auf dem Server in einem sichereren Bereich befinden. Wenn Sie es auf den Client stellen, ist es ziemlich einfach, den Quellcode für Javascript abzurufen, selbst wenn es sich um versteckte Skriptdateien handelt, auf die verwiesen wird.

11
Jon Raynor

Die Lösung ist einfacher. Client-Zertifikate. Ich erstelle ein Client-Zertifikat auf meinem Computer. Wenn ich mich auf einer Website registriere, führen wir einen Handshake mit meinem Client-Zertifikat und dem Server-Zertifikat durch.

Es werden keine Passwörter ausgetauscht, und selbst wenn jemand die Datenbank hackt, verfügt er nur über den öffentlichen Schlüssel meines Client-Zertifikats (der vom Server gesalzen und verschlüsselt werden sollte, um die Sicherheit zu erhöhen).

Das Client-Zertifikat kann auf einer Smartcard gespeichert (und mit einem Hauptkennwort in einen sicheren Online-Tresor hochgeladen werden).

Das Schöne daran ist, dass das Konzept des Phishing wegfällt. Sie geben niemals ein Passwort in eine Website ein, sondern schütteln nur die Hand mit dieser Website. Sie erhalten lediglich Ihren öffentlichen Schlüssel, der ohne privaten Schlüssel unbrauchbar ist. Die einzige Anfälligkeit besteht darin, während eines Handshakes eine Kollision zu finden, die auf einer einzelnen Website nur einmal funktioniert.

Microsoft hat versucht, so etwas in Windows mit Cardspace bereitzustellen, und hat es später als offenen Standard eingereicht. OAuth ist etwas ähnlich, basiert jedoch auf einer zwischengeschalteten "ausstellenden Partei". InfoCards können andererseits selbst ausgestellt werden. Dies ist die eigentliche Lösung für das Kennwortproblem ... das Entfernen von Kennwörtern insgesamt.

OAuth ist jedoch ein Schritt in die richtige Richtung.

6
Michael Brown

die meisten Antworten hier scheinen den Punkt des clientseitigen Passwort-Hashing völlig zu verfehlen.

der Punkt ist nicht, um den Zugriff auf den Server zu sichern, bei dem Sie sich anmelden, da das Abfangen eines Hashs nicht sicherer ist als das Abfangen eines Nur-Text-Passworts.

es geht wirklich darum, das Passwort des Benutzers zu sichern, was normalerweise weitaus wertvoller ist als der Zugriff auf einzelne Site-Anmeldungen, da die meisten Benutzer ihr Passwort für mehrere Sites wiederverwenden (sie sollten es nicht, aber die Realität ist, dass sie es tun es sollte also nicht abgewinkt werden).

ssl eignet sich hervorragend zum Schutz vor Mitm-Angriffen. Wenn jedoch eine Anmeldeanwendung auf dem Server gefährdet ist, schützt ssl Ihre Benutzer nicht. Wenn jemand böswillig Zugriff auf einen Webserver erhalten hat, kann er wahrscheinlich Kennwörter im Klartext abfangen, da Kennwörter in den meisten Fällen nur von einem Skript auf dem Server gehasht werden. Dann kann der Angreifer diese Passwörter auf anderen (normalerweise wertvolleren) Websites mit ähnlichen Benutzernamen testen.

sicherheit ist Tiefenverteidigung, und clientseitiges Hashing fügt einfach eine weitere Ebene hinzu. Denken Sie daran, dass der Schutz des Zugriffs auf Ihre eigene Website zwar wichtig ist, der Schutz der Geheimhaltung der Kennwörter Ihrer Benutzer jedoch aufgrund der Wiederverwendung von Kennwörtern auf anderen Websites weitaus wichtiger ist.

5
crutchy

Es ist definitiv möglich, und tatsächlich müssen Sie nicht auf eine Website warten.

Schauen Sie sich SuperGenPass an. Es ist ein Lesezeichen.

Es erkennt einfach Passwortfelder, verkettet, was Sie mit der Website-Domain eingeben, hasht es, zerfetzt es etwas, um nur "zugelassene" Zeichen im Passwort zu erhalten, und erst dann wird Ihr Hash-Passwort auf dem Draht gesendet.

Durch die Verwendung der Site-Domain erhalten Sie somit ein eindeutiges Passwort pro Site, auch wenn Sie immer dasselbe Passwort wiederverwenden.

Es ist nicht extrem sicher (base64-MD5), aber Sie verteilen eine sha-2-basierte Implementierung perfekt, wenn Sie dies wünschen.

Der einzige Nachteil ist, dass sich die Domain ändert. In diesem Fall müssen Sie die Website bitten, Ihr Passwort zurückzusetzen, da Sie es nicht selbst wiederherstellen können. Es kommt jedoch nicht oft vor, daher halte ich es für eine akzeptabler Kompromiss.

1
Matthieu M.

Ich mag die Antwort von X4u, aber meiner Meinung nach sollte so etwas in den Browser/die HTML-Spezifikation integriert werden - im Moment ist es nur die halbe Antwort.

Hier ist ein Problem, das ich als Benutzer habe: Ich habe keine Ahnung, ob mein Passwort beim Speichern in der Datenbank am anderen Ende gehasht wird. Die Zeilen zwischen mir und dem Server sind möglicherweise verschlüsselt, aber ich habe keine Ahnung, was mit meinem Passwort passiert, wenn es das Ziel erreicht - es wird möglicherweise als einfacher Text gespeichert. Der Datenbankadministrator verkauft möglicherweise die Datenbank und bevor Sie es wissen, kennt die ganze Welt Ihr Passwort.

Die meisten Benutzer verwenden Kennwörter wieder. Nicht technische Leute, weil sie es nicht besser wissen. Technische Leute, denn sobald Sie das 15. Passwort erreicht haben, haben die meisten Leute keine Chance, sich an sie zu erinnern, es sei denn, sie schreiben sie auf (was wir alle wissen, ist auch eine schlechte Idee).

Wenn Chrome oder IE oder was auch immer ich verwende) mir sagen könnte, dass ein Kennwortfeld sofort clientseitig gehasht wird, indem ein vom Server generiertes Salt verwendet wird und effektiv das Passwort selbst sandboxen - dann würde ich wissen, dass ich als Benutzer ein Passwort mit weniger Risiko wiederverwenden könnte. Ich möchte immer noch die verschlüsselten Kanäle und ich möchte nicht, dass während der Übertragung Traufe fallen.

Der Benutzer muss wissen, dass sein Passwort nicht einmal verfügbar ist, um an den Server gesendet zu werden - nur der Hash. Selbst mit der X4U-Lösung können sie derzeit nicht wissen, dass dies der Fall ist, da Sie nicht wissen, ob diese Technologie verwendet wird.

0
Chris Nevill