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.
javascript
security
client-relations
hashing
client-side
Martín Fixman
quelle
quelle
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 wirREALalle Nutzdaten zum und vom Server verschlüsselt und signiert haben. Die Kontomanipulation wurde gestoppt und ist danach nie wieder aufgetreten.Antworten:
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.).
quelle
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.
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.
quelle
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.
quelle
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.
quelle
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.
quelle
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.
quelle
passwordund oder ein SHA-256passwordmit etwas Salz, das dem Kunden bekannt ist, ein Mann in der Mitte kann es aufzeichnen.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.
quelle
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).
quelle