Gibt es irgendwelche SHA-256 javascript-Implementierungen, die allgemein als vertrauenswürdig angesehen?
Schreibe ich ein login für ein forum, und müssen hash das Passwort der client-Seite in javascript vor dem senden an den server. Ich habe Probleme, herauszufinden, welche SHA-256-Umsetzung kann ich eigentlich Vertrauen. Ich hatte erwartet, dort eine Art autoritative Skript, das jeder verwendet, aber ich finde viele verschiedene Projekte, die alle mit Ihren eigenen Implementierungen.
Erkenne ich mit anderen Menschen crypto ist immer ein Sprung des Glaubens, es sei denn, Sie qualifiziert sind, zu überprüfen Sie es selbst, und, dass es keine Universelle definition von "vertrauenswürdig", aber dies scheint wie etwas, das üblich und wichtig genug, dass es sollte eine Art Konsens über das, was zu verwenden. Bin ich einfach nur naiv?
Bearbeiten, denn es kommt viel in die Kommentare: ja, wir haben eine strengere hash wieder auf der server-Seite. Die client-Seite zu Hashen ist nicht das Endergebnis, das wir speichern in der Datenbank. Die client-Seite zu Hashen ist, weil der menschliche client es anfordert. Sie haben nicht einen speziellen Grund, warum, wahrscheinlich mögen Sie auch nur overkill.
Nicht einmal in der Nähe. "Don' T roll your own" gilt für das erfinden Ihre eigenen Algorithmus schreiben eigene Durchführung des-Algorithmus, entwickeln Sie Ihre eigenen Protokoll auf der Oberseite der Krypto-algorithmen, oder so ziemlich alles über die Verwendung als high-level-Abstraktion zur Verfügung. Wenn Sie denken, Sie werden sicher kleben, um einen sicheren Kern, und nur schreiben glue-code, den Sie sind gonna haben eine schlechte Zeit.
wenn du eine gehashte Passwort, ohne ein challenge/response-Protokoll, dann das gehashte Passwort IST das Passwort, und es ist wirklich die gleiche wie die übertragung des Passwort im Klartext.
Es gibt einige Wert in den Schutz des Benutzers Klartext-Passwort für alle anderen Websites, die Sie verwenden könnten, wenn nicht für unsere Website im besonderen. Es ist eine einfache Lösung, die vielleicht nicht uns helfen, sondern können potenziell helfen, den Benutzer, wenn wir die Schraube irgendwo. Und wie ich schon sagte, client-Anfrage, ich kann nichts dagegen tun auch wenn ich wollte.
Ich bin mehr als offen dafür sein, meine Meinung geändert 🙂 aber in diesem Fall verstehe ich nicht wirklich, wie Sie Ihre gilt. Wir hash das Passwort zweimal: einmal auf der client-Seite mit einem einfachen SHA-256, und einmal auf der server-Seite mit etwas mehr anspruchsvoll. Die erste zum Schutz der Klartext-im Falle eines MITM-oder ähnlich, und die zweite für brute-Schutz. Auch wenn Sie den Datenbank-und den admin-hash, die Sie nicht nutzen konnte, direkt zu validieren, die Anmeldung.
InformationsquelleAutor jono | 2013-08-19
Du musst angemeldet sein, um einen Kommentar abzugeben.
Den Stanford JS Crypto-Bibliothek enthält eine Implementierung von SHA-256. Während crypto in JS nicht so gut geprüft sind, ein Unterfangen wie andere Umsetzung-Plattformen, dies ist zumindest teilweise entwickelt, und in einem gewissen Umfang gesponsert, Dan Boneh, wer ist ein etablierter und vertrauenswürdiger name in der Kryptographie, und bedeutet, dass das Projekt einige Aufsicht von jemandem, der tatsächlich weiß, was er tut. Das Projekt wird auch unterstützt durch die NSF.
Es ist erwähnenswert, jedoch...
... , dass, wenn Sie hash das Passwort auf client-Seite vor dem Absenden, dann die hash das Passwort, und das ursprüngliche Kennwort irrelevant wird. Ein Angreifer braucht nur zum abfangen des hash, um die Identität des Benutzers annehmen, und wenn das hash gespeichert ist unverändert auf dem server, dann der server die Speicherung der wahr Passwort (der hash) in plain-text.
Damit Ihre Sicherheit ist nun schlimmer, weil Sie sich entschieden fügen Sie Ihre eigenen Verbesserungen zu dem, was bereits einem vertrauenswürdigen System.
wenn Sie hash auf dem server, dann bist du nicht speichern die übermittelten Passwort, aber Sie haben nicht Hinzugefügt jede Sicherheit über die übertragung des original-Passwort-im Gegensatz zu der übertragung der Passwort-hash, da in jedem Fall das, was du bist übertragung ist die echte Kennwort.
Stimmt, aber es ist nicht schlimmer als der Versand von nur einem Kennwort, das möglicherweise an anderer Stelle auf das Internet im Klartext.
Ich Stimme mit @NickBrunt . Es ist besser, wenn der Angreifer liest eine zufällige hash-string, der passen kann nur mit diesem speziellen app, anstatt der original-Passwort, die verwendet werden können, die in mehreren Orten.
Ich brauche Hilfe von client-Seite zu Hashen, weil ich nicht wollen, dass der server jemals sehen des Benutzers Klartext-Passwort. Nicht für zusätzliche Sicherheit, der service, die ich BIN, die Bereitstellung, sondern auf den Benutzer. Ich bin nicht nur speichern von Benutzer-hash gesalzen mit einer Konstanten Salz (Konstante pro Benutzer, nicht Global), aber auch re-Hashen mit einer zufälligen session-Salz jedes login, das ein wenig zusätzliche Sicherheit, die über das Netzwerk gegen sniffing. Wenn der server kompromittiert wird ist das Spiel vorbei, aber das ist wahr für alles, was nicht wirklich p2p sowieso.
InformationsquelleAutor tylerl
Auf https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest ich fand das snippet verwendet interne js-Modul:
Beachten Sie, dass
crypto.subtle
im nur aufhttps
oderlocalhost
- zum Beispiel für die lokale Entwicklung mitpython3 -m http.server
Sie müssen diese Zeile in Ihre/etc/hosts
:0.0.0.0 localhost
Neustart - und Sie können öffnen Sie
localhost:8000
mit arbeitencrypto.subtle
.Die builtin 'crypto' - Bibliothek tun sollte, einfach nur fein: nodejs.org/dist/latest-v11.x/docs/api/crypto.html
InformationsquelleAutor Vitaly Zdanevich
Forge's SHA-256-Implementierung ist schnell und zuverlässig.
Tests auf mehrere SHA-256 JavaScript-Implementierungen, gehen Sie zu http://brillout.github.io/test-javascript-hash-implementations/.
Die Ergebnisse auf meiner Maschine schlägt Schmieden, um die Schnellste Umsetzung und auch deutlich schneller als die Stanford Javascript Crypto Library (sjcl) erwähnt in der akzeptierten Antwort.
Forge ist 256 KB groß, aber das extrahieren der SHA-256-bezogenen code reduziert die Größe von 4,5 KB, siehe https://github.com/brillout/forge-sha256
InformationsquelleAutor brillout
Nein, es gibt keinen Weg, um den browser zu benutzen JavaScript zur Verbesserung der Passwort-Sicherheit. Ich empfehle Ihnen, Lesen Sie dieser Artikel. In Ihrem Fall, das größte problem ist das Henne-ei-problem:
[...]
Führt zu diesem:
Im Grunde, das problem ist Folgendes:
Oder alternativ
Hinweis: Auch, SHA-256 ist nicht geeignet, da es so einfach zu brute-force-ungesalzene nicht-iterierten Passwörter. Wenn Sie sich entscheiden, tun dies ohnehin, für eine Umsetzung der bcrypt, scrypt oder PBKDF2.
Du hast Recht, dass PBKDF2 verwendet werden soll, auf dem client. Die Wut gegen client-side javascript crypto davon ausgegangen, dass die erste Seite und die nachfolgenden Anträge haben die gleichen Sicherheits-Eigenschaften. Das ist offensichtlich nicht wahr, für browser-apps, auf denen die ursprüngliche Seite ist separat installiert werden und ist statisch. Es ist auch nicht wahr, für jede Seite mit cache-forever-Semantik. In diesen Fällen, es ist TOFU, das ist genau das gleiche wie bei der Installation einer client-side Programm. Dies kann auch wahr sein in komplexere setups, wo die portion von statischen und dynamischen Seiten werden getrennt auf dem server.
Ist es legitim, zu vermeiden, die system-Administratoren haben Zugriff auf Benutzer-Passwörter, so hashing in der client-Seite zu verhindern, Datenbankadministratoren oder andere IT-Profis, um zu sehen, Benutzer-Passwörter und versuchen Sie wieder zu verwenden, um den Zugriff auf andere Dienste/Systeme, da viele Benutzer wiederholen Sie Ihre Passwörter.
Alles, was Sie tun ist, erstellen Sie ein neues Kennwort, welches den "token + Passwort". Alle der ursprünglichen Probleme immer noch gelten. Zum Beispiel, kann ein Angreifer ersetzen Sie den JavaScript-code zum senden der token + Passwort.
Die Huhn-und-ei-problem nicht zu tun haben mit den Anfragen, die Sie senden. Das problem ist, dass Ihre Kunden mithilfe von JavaScript-code , dass es heruntergeladen über eine unsichere Verbindung zu tun, Sicherheit der Arbeit. Der einzige Weg, um sicher zu senden Sie JavaScript, um browser zu dienen, es über TLS aus, und sobald Sie das tun, werden Sie nicht brauchen, um etwas anderes zu tun, weil Ihr Anschluss ist bereits sicher. Es ist egal, was das Protokoll ist, wenn Sie JavaScript-code, den ein Angreifer kann nur ersetzen.
InformationsquelleAutor Brendan Long
Ich fand diese Umsetzung sehr einfach zu bedienen. Hat auch einen großzügigen BSD-style Lizenz:
jsSHA: https://github.com/Caligatio/jsSHA
Brauchte ich einen schnellen Weg, um den hex-string Darstellung eines SHA-256-hash. Es dauerte nur 3 Zeilen:
InformationsquelleAutor cobbzilla
Für Interessenten, dies ist der code für die Erstellung von SHA-256-hash über
sjcl
:InformationsquelleAutor Danny Sullivan
Neben der Stanford-lib, die tylerl erwähnt. Ich fand jsrsasign sehr nützlich (Github-repo hier:https://github.com/kjur/jsrsasign). Ich weiß nicht genau wie vertrauenswürdig es ist, aber ich habe die API von SHA256 -, Base64 -, RSA, x509-etc. und es funktioniert ziemlich gut. In der Tat, es enthält die Stanford-lib als gut.
Wenn alles, was Sie tun möchten ist, SHA256, jsrsasign vielleicht ein overkill. Aber wenn Sie haben andere Bedürfnisse in den zugehörigen Bereich, ich glaube, es ist eine gute Passform.
Einverstanden, aber um fair zu sein,ich beantwortete diese Frage in 2015, während Mozillas web-crypto-API-Spezifikation veröffentlicht wurde Jan 2017
InformationsquelleAutor Faraway