Warum haben fast keine Webseiten Passwörter im Client, bevor sie gesendet wurden (und sie erneut auf dem Server gehasht haben), um sich gegen die Wiederverwendung von Passwörtern zu schützen?

46

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

Ich frage mich also, wie schwer es ist, eine Webseite zu erstellen, die Passwörter auf dem Clientcomputer (mit Javascript) hasht, bevor sie an den Server gesendet werden, wo sie erneut hasht werden? Theoretisch bedeutet dies keine zusätzliche Sicherheit, aber in der Praxis kann dies zum Schutz vor "betrügerischen Sites" verwendet werden, die Ihr Kennwort nicht im Server haben.

— Martín Fixman
quelle

18

Ein im Klartext gesendetes Hash-Passwort ist nicht besser als ein im Klartext gesendetes Passwort, wenn der Server nur Hashes vergleicht. Man in the Middle-Angriffe lieben diese Art von "Sicherheit"

3

Die beste Lösung ist (imo) ein clientseitiger Passwortmanager. Auf diese Weise können Sie eine zufällige Zeichenfolge als Kennwort generieren und sich nicht darauf verlassen, dass der Server Sie "schützt".

— Dean Harding

2

@Jarrod - das klingt für mich so, als würden verschiedene Websites, die verschiedene clientseitige Hashalgorithmen verwenden, den von diesem Comic beschriebenen Angriff verhindern. Ein häufig wiederverwendetes Passwort wird durch diese unterschiedlichen Hash-Algorithmen zu vielen unterschiedlichen Passwörtern. Diese clientseitige Hash-Berechnung verhindert nicht, dass andere Arten von Sicherheit angewendet werden - beispielsweise das Senden des Hashs über eine sichere Verbindung.

— Steve314

2

@ Steve314 Mein Punkt ist, dass alles auf dem Client standardmäßig kompromittiert ist. Sie können Hash und Hash und Hash, wenn es auf dem Client durchgeführt und an den Server weitergegeben wird clear, ist es zu diesem Zeitpunkt nur mathematische Masturbation. Ich musste ein von mir geerbtes System reparieren, das genau so entworfen wurde, wie Sie und das OP es beschreiben. Es wurde ständig von Teenagern mit Wireshark gehackt. Wir haben es erst gesperrt, als wir REALalle Nutzdaten zum und vom Server verschlüsselt und signiert haben. Die Kontomanipulation wurde gestoppt und ist danach nie wieder aufgetreten.

5

Es hört sich so an, als ob Sie sich vor betrügerischen Websites schützen möchten, indem Sie die betrügerischen Websites auffordern, eine bessere Sicherheit einzurichten. ?

— pc1oad1etter

46

Warum wird es nicht verwendet? Weil es eine Menge zusätzlicher Arbeit für den Nullgewinn ist. Ein solches System wäre nicht sicherer. Es ist möglicherweise sogar weniger sicher, da es den falschen Eindruck erweckt, sicherer zu sein, und Benutzer dazu veranlasst, weniger sichere Methoden anzuwenden (wie die Wiederverwendung von Kennwörtern, Wörterbuchkennwörtern usw.).

— Rein Henrichs
quelle

2

Dies ist die bisher beste Antwort.

1

Es ist wie bei der Blu-Ray- und DVD-Verschlüsselung. Zum Entsperren ist nicht einmal ein Schlüssel erforderlich. Der einzige "Schutz", den es bot, war, dass der Kauf einer CD zum ersten Mal, als DVDs herauskamen, mehr kostete als der Kauf einer vollständigen Kopie des Films. Natürlich kann man jetzt eine DVD für einen Dollar kaufen und noch mehr ist die Tatsache, dass die Schlüssel jetzt öffentlich bekannt sind. Gleiches passiert mit Blu-Ray

— Michael Brown

2

Ich denke, dass das Hashing eines Passworts auf der Client-Seite die Sicherheit erhöht. Wenn ich mithöre, kann ich nur Ihren Hash sehen, nicht Ihr Passwort. Wenn der Server eine Herausforderung sendet (wie er sollte), ist der Hash nicht einmal wieder verwendbar.

— Andomar

2

Ich denke, dass der Ansatz von x4u sehr gut für einige Anwendungen geeignet ist, bei denen Sicherheitsanforderungen zwischen der Übertragung von Passwörtern über das Kabel und der Verwendung von Zertifikaten liegen. Ich denke, einige der Neinsager übersehen, dass das Hashing des Passworts, bevor es auf die Leitung geht, zusätzlich zu der standardmäßigen serverseitigen Behandlung von Anmeldeinformationen erfolgt. Die Frage ist also: Verbessert der Vorschlag von x4u die Sicherheit im Szenario der Übermittlung von Passwörtern über das Festnetz oder nicht? Ich sage es tut. Der Schlüssel zur Realisierung liegt in der Verwendung von Passwort-Salzen.

— LOAS

6

Der richtige Weg, um MITM-Angriffe zu verhindern, ist die Ende-zu-Ende-Verschlüsselung. TLS (https) existiert: benutze es. Erfinde keine eigenen Kryptoschemata.

— Rein Henrichs

14

Theoretisch bedeutet dies keine zusätzliche Sicherheit, aber in der Praxis kann dies zum Schutz vor "betrügerischen Sites" verwendet werden, die Ihr Kennwort nicht im Server haben.

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 gehashte Passwort würde dann zum Passwort.

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

Wie wäre es, wenn Sie nicht dasselbe Passwort für mehr als eine Site verwenden? Der Grund, warum Websites das Passwort in der Theorie haben, ist, um den Zugriff auf Ihr Konto zu verhindern, wenn SIE kompromittiert werden. Das gleiche Passwort für mehrere Websites zu verwenden, ist einfach dumm.

Wenn Sie Javascript verwenden würden, müsste der "Hacker" nur die gleiche Methode für die Hash-Hash-Passwörter anwenden. Sobald Sie die Hash-Informationen haben, ist es nur noch Zeit, das Passwort zu berechnen -> derselbe Hash in der Datenbank, der den Zugriff auf ein Konto verhindert.

— Ramhound
quelle

1

Wenn Ihr Browser es immer auf die gleiche Weise hascht, dann kann Ihr Hash ja überall als Passwort verwendet werden. Aber was ist, wenn Browser ein Salt basierend auf der Site (vielleicht der Domain?) Zugewiesen haben, bevor sie es gehasht und an die Site gesendet haben? Ich halte das für eine interessante Idee.

— Tesserex

2

Wenn es sich bei dem Client um eine Kompromittierung handelt, ist jedes Salz auf dem Client unübersehbar. Dies ist eine unlogische Frage. Wenn Sie die Antwort von @ Ramhound nicht verstehen, sollten Sie keinen Code schreiben, der sicher sein muss, und sich von Anfang an über Sicherheit und Kryptografie informieren.

3

Wenn Sie das Originalplakat zitieren, formatieren Sie bitte den Text als solchen (wählen Sie den Text aus und verwenden Sie das Anführungszeichen direkt über dem Herausgeber)

— Marjan Venema

1

Jarrod, bitte folge deinem eigenen Rat und informiere dich, bevor du lächerliche Behauptungen aufstellst. Ein Mann im mittleren Angriff ist gegen sichere Hash-Funktionen mit angemessener Salzlänge nutzlos. Mein Vorschlag lautet in keiner Weise "Sicherheit durch Unbekanntheit". Er basiert auf dem, was derzeit von den Experten auf diesem Gebiet bekannt und akzeptiert ist, und wird in vielen Protokollen auf die gleiche Weise verwendet. Es ist nicht meine Erfindung, ich habe nur ein gut verstandenes Verfahren auf ein Website-Login angewendet. Ihre falschen Annahmen gewinnen keine Substanz durch die Tatsache, dass sie offensichtlich auch von vielen anderen geteilt werden.

— x4u

3

Wenn das Salz dem Client bekannt ist und es von einem Server im Klartext gesendet wird, weiß es auch alles in der Mitte. Nie gesagt, ich musste den Hash rückgängig machen, wenn Sie das Salz auf dem Client kennen, dann ist nicht sicher.

11

Weil es wenig zu nichts beitragen würde. Der Grund dafür ist, dass der Hacker keine Liste gültiger Kennwörter hat, wenn Ihre Datenbank gehackt wird, sondern nur Hashes. Daher konnten sie sich nicht als Benutzer ausgeben. Ihr System kennt das Passwort nicht.

Secure basiert auf SSL-Zertifikaten und einer Art Authentifizierung. Ich möchte, dass meine Benutzer ein Passwort angeben, damit ich den Hash daraus berechnen kann.

Der Hash-Algorithmus befindet sich außerdem auf dem Server in einem sichereren Bereich. Wenn man es auf den Client legt, ist es ziemlich einfach, den Quellcode für Javascript zu bekommen, selbst wenn seine versteckten Skriptdateien darauf verweisen.

— Jon Raynor
quelle

3

Das ist die beste Antwort. Sie sollten auf der Transportebene verschlüsseln. Ohne das ist der Rest nicht sicher. Ja, Sie könnten eine Verschlüsselungsfunktion schreiben ... aber diese Funktion ist für (böswillige) Endbenutzer sichtbar. Verwenden Sie SSL.

— pc1oad1etter

Die Sicherheit eines Hashing-Algorithmus sollte nicht davon abhängen, ob er geheim ist. Hashing-Algorithmen für die Sicherheit sollten Einwegfunktionen sein: Selbst wenn Sie den Code haben, ist es schwierig, ihn rückgängig zu machen. Im Gegenteil, Sie sollten eine bekannte Hash-Bibliothek verwenden, die nur für Kennwörter entwickelt wurde. Wenn es nicht bekannt ist, ist es mit ziemlicher Sicherheit fehlerhaft oder zweckentfremdet.

— Leewz

6

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, ist alles, was er hat, der öffentliche Schlüssel meines Client-Zertifikats (das vom Server aus Sicherheitsgründen gesalzt und verschlüsselt werden sollte).

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

Das Schöne daran ist, dass es das Konzept des Phishing aufhebt ... Sie geben niemals ein Passwort in eine Website ein, sondern geben diese Website nur per Handschlag weiter. Sie erhalten lediglich Ihren öffentlichen Schlüssel, der ohne einen 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, stützt sich jedoch auf eine zwischengeschaltete "ausstellende Partei". InfoCards können dagegen selbst ausgestellt werden. Das ist die wirkliche Lösung für das Passwortproblem ... das Entfernen von Passwörtern insgesamt.

OAuth ist jedoch ein Schritt in die richtige Richtung.

— Michael Brown
quelle

5

Während Client-Zertifikate für einige Anwendungsfälle eine vernünftige Methode darstellen, können sie nicht einfach zu einem Website-Login hinzugefügt werden. Sie erfordern viel Zusammenarbeit von den Benutzern und hängen davon ab, wie sicher der private Schlüssel des Benutzers ist. Die Verwendung eines privaten Schlüssels kann entweder sicher oder bequem sein, jedoch nicht beides gleichzeitig.

— x4u

5

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

Es geht nicht darum, den Zugriff auf den Server zu sichern, auf dem Sie sich anmelden, da das Abfangen eines Hashs nicht sicherer ist als das Abfangen eines Nur-Text-Kennworts.

Es geht wirklich darum, das Kennwort des Benutzers zu sichern. Dies ist in der Regel weitaus wertvoller als der Zugriff auf einzelne Websites, da die meisten Benutzer ihr Kennwort für mehrere Websites wiederverwenden ).

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 in böswilliger Absicht auf einen Webserver zugegriffen hat, kann er wahrscheinlich Passwörter im Klartext abfangen, da Passwö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) Sites mit ähnlichen Benutzernamen ausprobieren.

Sicherheit ist eine tiefgreifende Verteidigung, und clientseitiges Hashing fügt einfach eine weitere Ebene hinzu. Denken Sie daran, dass der Schutz des Zugriffs auf Ihre eigene Site wichtig ist, der Schutz der Geheimhaltung der Passwörter Ihrer Benutzer jedoch aufgrund der Wiederverwendung von Passwörtern auf anderen Sites weitaus wichtiger ist.

— knusprig
quelle

2

Die akzeptierte Antwort teilt Ihren Standpunkt ganz gut. Auch wenn "die meisten Antworten" dies nicht tun und Ihre Antwort nicht wirklich wertvoll ist, macht es keinen Sinn, diese Frage erneut zu beantworten.

— Frank

Es ist wahrscheinlich eher ein Kommentar als eine Antwort (ich entschuldige mich dafür, dass ich nicht herausgefunden habe, wie ich dem akzeptierten Antwortkommentarthread etwas hinzufügen soll), und obwohl mein Punkt in der akzeptierten Antwort geteilt wird, war es anscheinend nicht klar genug, da die Antworten darauf zu sein scheinen es noch abzubürsten. danke für das feedback

— crutchy

@Frank Die akzeptierte Antwort ist zu lang, um sie lesen zu können. Es wird viel zu detailliert darauf eingegangen, wie dies implementiert werden kann, und es werden die Vorteile zum Ende hin übergangen. Ein TL; DR in einer anderen Antwort ist von Vorteil.

— Jules

2

@Jules: Deshalb gibt es eine Bearbeitung.

— Robert Harvey

1

@JarrodRoberson Ich denke du verwechselst nicht mehr sicher mit unsicher ? Wenn MITM eintritt, ist der Zugriff auf die Site bereits verweigert, nicht wahr? Es sei denn, Sie verwenden ein Client-Zertifikat anstelle eines Kennworts, was für normale Benutzer zu komplex wäre . So wie ich es sehe, verhindert das clientseitige Hashing, dass dasselbe Passwort auf anderen Sites kompromittiert wird, vorausgesetzt, jeder Hashing-Algorithmus ist einzigartig. Es ist vielleicht nicht sicherer, aber auch nicht weniger sicher? Warum treibst du das so hart an? Ich bin auf Meta gestoßen, und das ist die beste Antwort, die ich bisher gesehen habe.

— ZypA13510

1

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

Schauen Sie sich SuperGenPass an . Es ist ein Bookmarklet.

Es erkennt einfach Passwortfelder, verkettet, was Sie mit der Website-Domain eingeben, hascht es, verstümmelt es ein wenig, um nur "zugelassene" Zeichen im Passwort zu erhalten, und nur dann wird Ihr Hash-Passwort über die Leitung 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, wenn sich die Domain ändert. In diesem Fall müssen Sie die Website auffordern, Ihr Passwort zurückzusetzen, da Sie es nicht selbst wiederherstellen können akzeptabler Kompromiss.

— Matthieu M.
quelle

Dies ist, was ich dachte, als ich die Frage las; Es ist praktisch nutzlos für Websites, ihre eigenen clientseitigen Hashing-Vorgänge durchzuführen, aber eine Browser-Erweiterung, die dies tut (unter Verwendung von etwas Salz basierend auf der Domäne), würde das mit der Wiederverwendung von Kennwörtern verbundene Risiko effektiv aufheben. Der spaßige Teil kommt natürlich, wenn Sie versuchen, sich von einem anderen Computer aus anzumelden ...

— Aaronaught,

3

Dies ist nicht sicherer als jedes andere Schema, das das Passwort im Klartext weitergibt. Dadurch wird das Kennwort eindeutig, aber es ist immer noch nicht verschlüsselt . Wenn ich jedoch einen Server in der Mitte habe, kann ich das komplizierte, aber immer noch eindeutige Kennwort abrufen und es so oft verwenden, wie ich möchte. Es ändert sich nicht. Ein Hash ist kein Wundermittel, es ist nicht einmal Verschlüsselung, sie werden kryptografische Hashes genannt, aber das bedeutet nicht, dass es sich um Verschlüsselung handelt. Egal ob mein Passwort passwordund oder ein SHA-256 passwordmit etwas Salz, das dem Kunden bekannt ist, ein Mann in der Mitte kann es aufzeichnen.

@Jarrod Roberson: Sie können das Passwort natürlich verwenden, aber Sie können es nicht für einen anderen meiner Accounts wiederverwenden, worum es geht. Wenn einer der Websites, auf die ich mich verbinde, sein Passwort gestohlen wurde und diese im Klartext gespeichert wurden, sind meine anderen Konten sicher.

— Matthieu M.

@Aaronaught: da leuchtet es eigentlich. Da das gesendete Kennwort ausschließlich von der angemeldeten Website-Domain und einem Hauptkennwort Ihrer Wahl abgeleitet ist, können Sie sich von jedem Computer (und Browser) aus anmelden, solange Sie über das Lesezeichen verfügen. Deshalb ist es etwas komfortabler als ein Zertifikat.

— Matthieu M.

6

@Jarrod: Dies ist keine Sicherheitsmaßnahme für die Site , sondern eine Sicherheitsmaßnahme für den Benutzer . Wenn jeder ein solches Schema verwenden würde, wäre die Wiederverwendung von Passwörtern kein Problem. Ein MITM-Schema könnte das vom Client gehashte Kennwort verwenden, um Zugriff auf diese Site zu erhalten, jedoch nur auf diese Site. Hier liegt die Verbesserung. Normalerweise erwarten Sie, dass Sie durch einfaches Knacken eines Kennworts auf viele Konten zugreifen können , da dieses Kennwort wahrscheinlich wiederverwendet wird. In diesem Fall ist das geknackte Passwort garantiert nur für die Site oder Datenbank gültig, in der es gefunden wurde.

— Aaronaught

0

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 am anderen Ende gehasht wird, wenn es in der Datenbank gespeichert wird. Die Leitungen 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. Möglicherweise verkauft der Datenbankadministrator die Datenbank, und bevor Sie es wissen, kennt die ganze Welt Ihr Passwort.

Die meisten Benutzer verwenden Kennwörter erneut. 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 eine Passwortbox sofort clientseitig gehasht wird, indem ein vom Server generiertes Salt verwendet wird und das Passwort selbst effektiv in einer Sandbox gespeichert wird - dann würde ich wissen, dass ich es als Benutzer wiederverwenden könnte ein Passwort mit weniger Risiko. Ich möchte immer noch die verschlüsselten Kanäle, und ich möchte nicht, dass während der Übertragung irgendwelche Lauschangriffe auftreten.

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

— Chris Nevill
quelle

1

Es ist in den Browser integriert. Die Digest-Authentifizierung wird nachgeschlagen, und Sie sehen die Schritte, die in http ausgeführt werden, um ein Passwort-Hashing mit zusätzlichen Informationen zu erhalten, das auf dem Server überprüft wird.

— gbjbaanb

-1

Ich denke, es ist eine gute Methode, wenn Sie so etwas wie ein Framework, ein CMS, eine Forensoftware usw. erstellen, bei der Sie die Server, auf denen es möglicherweise installiert ist, nicht kontrollieren. Das heißt, JA, Sie sollten immer die Verwendung von SSL für Anmeldungen und angemeldete Aktivitäten empfehlen, aber einige Sites, die Ihr Framework / cms verwenden, haben es nicht, sodass sie trotzdem davon profitieren können.

Wie andere darauf hingewiesen haben, besteht der Vorteil hier NICHT darin, dass sich bei einem MITM-Angriff niemand anders als Sie an dieser bestimmten Site anmelden kann, sondern dass dieser Angreifer dann nicht dieselbe Kombination aus Benutzername und Kennwort verwenden kann Melden Sie sich bei möglicherweise Dutzenden anderer Websites an, auf denen Sie Konten haben.

Solch ein Schema sollte entweder mit einem zufälligen Salt oder einer Kombination aus sitespezifischen und benutzernamensspezifischen Salt gesalzen werden, damit jemand, der das Passwort erhält, es nicht für denselben Benutzernamen auf anderen Sites verwenden kann (auch Sites, die dasselbe Hashing-Schema verwenden) ), noch gegen andere Benutzer der Website Website, die möglicherweise das gleiche Passwort haben.

Andere haben vorgeschlagen, dass Benutzer eindeutige Kennwörter für jede von ihnen verwendete Site erstellen oder Kennwortmanager verwenden sollten. Obwohl dies theoretisch ein solider Rat ist, wissen wir alle, dass dies eine Torheit ist, auf die wir uns in der realen Welt verlassen können. Der Prozentsatz der Benutzer, die eines dieser Dinge tun, ist gering, und ich bezweifle, dass sich dies bald ändern wird.

Ein Javascript-Passwort-Hasher ist also so gut wie das Mindeste, was ein Framework- / CMS-Entwickler tun kann, um den Schaden zu begrenzen, den jemand beim Abfangen von Passwörtern erleidet (was heutzutage über WLAN-Netzwerke leicht möglich ist), wenn sowohl der Websitebesitzer als auch die Endbenutzer fahrlässig vorgehen über die Sicherheit (die sie wahrscheinlich sind).

— matthewv789
quelle