Ich weiß, dass HTTPS das Problem lösen kann, aber ich werde dennoch angewiesen, das Kennwort vor dem Senden über das Netzwerk gemäß unseren Organisationsrichtlinien zu verschlüsseln.

This definiert Ihre Situation wirklich.

Grundsätzlich haben Sie eine einfache Lösung, die Sie trotzdem verwenden sollten (verwenden Sie HTTPS), schon allein deshalb, weil ein aktiver Angreifer ohne HTTPS die Verbindung nach dem Authentifizierungsschritt entführen könnte, unabhängig davon von jeder "Codierung" und jedem Hashing, die Sie für das Passwort verwenden (ein Angreifer, der in der Lage ist, einen Man-in-the-Middle-Angriff auszuführen, wird erfolgreich sein, unabhängig davon, wie viel Sie rituell mit Hash-Funktionen und tanzen Verschlüsselung). Dann haben Sie auch eine Richtlinie, die sowohl idiotisch als auch administrativ unvermeidbar ist. Ihr Problem ist dann: Wie können Sie die Dinge richtig machen und trotzdem die "Richtlinie" einhalten?

Beachten Sie, dass die Richtlinie auf mehreren Ebenen wenig Sinn macht. Das Fehlen von SSL macht das Protokoll nicht nur anfällig für Entführungen. Aber auch jede Art von "Kodierung" nützt passiven Angreifern nichts. Der Grund dafür ist, dass wenn das Protokoll "der Client zeigt das" verschlüsselte "Passwort" lautet, ein passiver Lauscher einfach dieses "verschlüsselte Passwort" überprüft und es selbst sendet - daher verbessert diese Art der Codierung die Sicherheit in keinem Fall Weg. Einige Leute fühlen sich dadurch sicherer , weil sie Kryptographie als eine Art Barbecue-Sauce verstehen ("je mehr wir überall streuen, desto besser wird es").

Was ich vorschlage, ist dass Sie Folgendes tun:

1. Versuchen Sie zunächst, die Idee zu verkaufen, dass "HTTPS" die "Codierung" verkörpert. Mit anderen Worten, wenn Sie das Kennwort innerhalb eines SSL-Tunnels senden, halten Sie sich bereits an die Richtlinie, da das Kennwort zusammen mit den übrigen Daten ordnungsgemäß codiert (und tatsächlich verschlüsselt ) ist.

2. Wenn der Dummheitsbefall schwerwiegender ist und ein Auditor (nennen wir ihn Bob) immer noch einen Anfall über Ihren Mangel an "Codierung" macht, versuchen Sie, auf der Client-Seite eine reversible Codierung anzuwenden. Z.B. Wenden Sie vor dem Senden des Passworts Base64 an. Dies bedeutet, dass, wenn das Passwort "bobsucks" lautet, (natürlich innerhalb von SSL) "Ym9ic3Vja3M =" gesendet wird und Bob glücklicher ist, da die letztere Zeichenfolge offensichtlich a ist viel sicherer.

ol>

Der wichtige Punkt hierbei ist, dass die Lösung auch keinen Sinn ergibt, da die Anforderung keinen Sinn ergibt.

Sie haben keine Sicherheit ohne Authentifizierung

Um es weiter zu erläutern, verwende ich die JCryption API zum Verschlüsseln des Kennworts mit AES. Der über das Netzwerk übertragene Wert lautet also AES (SHA1 (MD5 (einfaches Kennwort)) ))) Jetzt möchte ich MD5 durch Bcryptonly ersetzen. Der Rest der Dinge bleibt unverändert. Dieser Ansatz funktioniert sogar gegen "Man in the Middle Attack" .

Nein, das tut er nicht. Ich kann dies nicht stark genug ausdrücken. Jetzt kann ich Sie möglicherweise nicht davon überzeugen, https zu verwenden (Sie haben möglicherweise nicht einmal eine Wahl), aber ich hoffe, ich kann Sie davon überzeugen, dass es absolut unsicher ist und dass Sie daran glauben Es ist falsch, etwas Sicherheit zu bieten. Wenn Sie gezwungen sind, ohne TLS / SSL voranzukommen, können Sie allen Beteiligten zumindest klar machen, dass das System anfällig ist und als "leicht zu umgehende Wohlfühlsicherheit" bezeichnet werden sollte. Ein Script-Kiddie, der einen MITM-Hotspot bei Ihren lokalen Starbucks ausführt, kann Ihre Benutzer fälschen und Anmeldeinformationen stehlen oder Sitzungen entführen, sodass keine hoch entwickelten Fähigkeiten oder komplexen Angriffe erforderlich sind.

Wenn der Kommunikationskanal unsicher ist, sollten Sie dies tun Ich habe keine Erwartung, dass der von Ihnen gesendete Code der Code ist, der tatsächlich vom Client ausgeführt wird. Es gibt einen Grund, warum es https (sicheres http) heißt, nicht nur httpe (verschlüsseltes http). Sicherheit ist mehr als nur Verschlüsselung. Verschlüsselungskommunikation ohne Authentifizierung ist sinnlos.

Einige Dinge, über die Sie nachdenken sollten:

• Woher wissen Ihre Benutzer ohne https überhaupt, dass sie sich auf Ihrer Anmeldeseite befinden?

Was ist, wenn ich zusätzlich zur Verschlüsselung meine eigene benutzerdefinierte Authentifizierung durchführe

So einfach ist das nicht. Das Bootstrapping eines sicheren Kanals über einen unsicheren Kanal ist kein triviales Problem. Theoretisch könnten Sie ein benutzerdefiniertes Protokoll erstellen, das alle Aspekte von https repliziert, einschließlich Protokollverhandlung, Serverauthentifizierung, Infrastruktur öffentlicher Schlüssel, Schlüsselaustausch, Verschlüsselung, Nachrichtenintegrität und Sperrung (und ich bin sicher, dass ich noch viel mehr vergessen habe). Sobald Sie fertig sind, ist es genauso groß und komplex wie TLS. Nehmen wir auch an, es hatte weniger Fehler als jede andere TLS-Implementierung und Sie könnten es in weniger als ein paar Jahren tun, Sie hätten immer noch ein fast unmögliches Problem. Wie bringen Sie diese clientseitigen Komponenten zum Client? "Oh sicher, der Client muss es sicher herunterladen ... ähm, warte". Wenn es einfach erscheint, sichere Kommunikation über einen unsicheren Kanal zu booten, dann haben Sie ehrlich gesagt nicht tief genug geschaut, es sind Schildkröten bis zum Ende.

Lassen Sie mich jetzt klar sein, TLS hat viele Probleme, und das Das CA-System hat auch viele Probleme. Ich werde sicherlich nicht so tun, als wäre es perfekt, aber sichere Kommunikation ist ein solches Henne-Ei-Problem, dass es die beste Lösung ist, die wir haben.

Client-seitiges Hashing kann über https

Aus Ihrer Formulierung geht hervor, dass Sie die Frage als "clientseitiges Hashing ODER serverseitiges Hashing über https" betrachten, aber ich hoffe, Sie können sehen, dass dies ein Trugschluss ist. Sie benötigen https, unabhängig davon, wie Sie Ihre Benutzer authentifizieren. Wenn Sie also akzeptieren, dass Sie https benötigen, lautet die Frage: "Warum oder wann ist es sinnvoll, clientseitiges Hashing (über https) anstelle von serverseitigem Hashing (über https) zu verwenden? In den meisten Fällen ist dies nicht der Fall." Das clientseitige Hashing ist komplexer und nicht sicherer, hat jedoch einen Vorteil: Der Server kennt das Kennwort nicht, was beim serverseitigen Hashing nicht der Fall ist. In einigen Szenarien möchten Sie dies Sie können einen Schlüssel, den Sie nicht haben, nicht verlieren, und Sie können nicht gezwungen werden, die Dateien eines Kunden zu entschlüsseln, wenn er Ihnen nie den Entschlüsselungsschlüssel gegeben hat. Es gibt also Szenarien, in denen dies möglicherweise obligatorisch ist Voraussetzung, aber es sollte Teil des Projektdesigns sein, keine willkürliche Entscheidung. Wenn Sie spezielle Fragen zum Umgang mit Null-Wissensszenarien haben, ist dies besser als neue Frage zu tun.

bcrypt ist nicht für diese Art von clientseitigem Hashing gedacht.

Eine Schlüsseleigenschaft von bcrypt besteht darin, dass die meisten Implementierungen bei zwei unabhängigen Ausführungen mit demselben Klartext unterschiedliche Hashes erzeugen. Dies ist auf die Verwendung eines Salt zurückzuführen, das es schwierig macht, festzustellen, ob zwei verschiedene Benutzer dasselbe Kennwort haben.

Im Gegensatz dazu müssen Anmeldeformulare jedes Mal dieselben Daten empfangen. Wie würden Sie sonst überprüfen, ob das Kennwort, das der Benutzer heute eingegeben hat, mit dem übereinstimmt, das er gestern eingegeben hat?

Sie haben also einen Algorithmus, mit dem jeweils unterschiedliche Daten erzeugt werden Sie geben es in eine Anwendung ein, die überprüfen muss, ob die Daten jedes Mal gleich sind. Dies ist wahrscheinlich ein Hinweis darauf, dass der Algorithmus nicht wie beabsichtigt verwendet wird.

Idealerweise sollten Sie bcrypt verwenden, um Kennwörter auf dem Server zu hashen . Dafür wurde bcrypt entwickelt: Schutz von Benutzerkennwörtern in Zeiten, in denen sich der Klartext nicht im Speicher befindet, was bei weitem der häufigste Zustand ist (z. B. würden DB-Dumps bei korrekter Implementierung nur das Hash-Passwort und nicht den Klartext anzeigen).

Ich persönlich sehe auch einen Wert im clientseitigen Hashing, da es zum Schutz vor Angreifern beiträgt, die den Datenverkehr abhören können (oder über Serverzugriff verfügen). Ich kenne jedoch keine Möglichkeit, clientseitiges Hashing so sicher wie serverseitiges bcrypt zu machen. Deshalb sollten Sie weiterhin serverseitiges bcrypt verwenden.

Wenn Sie bcrypt client verwenden müssen -side, verwenden Sie ein statisches Salt

Wenn Sie bcrypt für das clientseitige Hashing eines Anmeldeformulars verwenden möchten und möchten, dass es ein Drop-In-Ersatz für MD5 ist, müssen Sie es verwenden ein statisches Salz. Vor allem, wenn Sie es durch SHA1 leiten, da dies sowohl das bcrypt-Salz als auch die Hash-Daten selbst beschädigen würde.

Dies verstößt gegen mehrere Entwurfsannahmen von bcrypt (z. B. immer die Verwendung eines zufälligen Salzes). natürlich.

Ich würde persönlich empfehlen, den Benutzernamen als Salt zu verwenden (so dass es schwierig ist zu sagen, ob zwei verschiedene Benutzer dasselbe Passwort haben). Ich kenne jedoch keine Forschung, die in diesem Zusammenhang zum Salzen durchgeführt wurde.

AES (oder eine symmetrische Chiffre) ist auch hier nutzlos.

Denken Sie daran, dass AES ist ein symmetrischer Algorithmus, dh Sie benötigen denselben Schlüssel zum Entschlüsseln von und zum Verschlüsseln von Daten.

Was bedeutet dies für Sie? Nun, Sie haben wahrscheinlich Ihren Verschlüsselungsschlüssel in der JavaScript-Quelle, die jedem Client bereitgestellt wird, der Ihre Anmeldeseite besucht. AES ist eine symmetrische Verschlüsselung, daher sollte Ihr Verschlüsselungsschlüssel (der mit dem Entschlüsselungsschlüssel identisch ist) privat gehalten werden. Mit anderen Worten, Ihr privater Schlüssel ist der Welt bekannt - er bietet derzeit praktisch keine Sicherheit.

Stattdessen sollten Sie Kryptografie mit öffentlichem Schlüssel verwenden. wie PGP oder HTTPS (technisch gesehen verwendet HTTPS einen hybriden Ansatz). Im Ernst, verwenden Sie einfach HTTPS , es sei denn, Ihre Organisation verweigert Ihnen aus irgendeinem Grund die Vergabe eines SSL-Zertifikats. Denken Sie daran, dass PGP nicht wirklich vor aktiven MITM-Angriffen schützt, aber zumindest vor Abhören.

Die beste Lösung ist: Nicht.

Wenn Sie die Kennwörter über HTTPS senden, bietet das Hashing keine zusätzliche Sicherheit.

Wenn Sie die Kennwörter senden Über einfaches HTTP kann ein Angreifer das Hash-Passwort abrufen und sich damit selbst anmelden. Alternativ können sie das JavaScript manipulieren, um das Kennwort vor dem Hashing an sie zu senden. In beiden Fällen bietet das Hashing des Kennworts keine Sicherheit.

Da Sie sich verpflichtet fühlen, diese Richtlinie umzusetzen, werde ich Ihre Frage direkt beantworten. Aber verstehen Sie, dass BCrypt und MD5 sehr unterschiedlich sind. BCrypt leistet absichtlich erhebliche Arbeit, während MD5 erheblich weniger leistet. Sie müssen sich also mit Versprechungen befassen:

  <! - https://github.com/nevins-b/ Javascript-bcrypt --><script src = 'bCrypt.js'>< / script><script src =' isaac.js'>< / script><script> // ... der Code, dann: var bcrypt = new bcrypt (); bcrypt.hashpw ('einfaches Passwort', bcrypt.gensalt (), Funktion (Hash) {var cipher = AES (SHA1 (Hash)); // jetzt haben Sie Ihren "sicheren" Hash}); < / script>  

Ich fordere Sie auf, den weisen Rat in den anderen Antworten zu berücksichtigen. Die Szenarien, in denen diese Richtlinie einen Mehrwert bietet, sind selten. Fragen Sie sich daher: Warum doppelte Arbeit in redundante Infrastruktur investieren, die keine Sicherheit bietet und die Benutzererfahrung verlangsamt?

Referenzen:

1. Die Transportverschlüsselung schützt alle Geheimnisse.

2. Das Senden eines Hashs entspricht dem Senden eines Passworts und das Generieren eines sicheren Hashs ist notwendigerweise langsam.

3. Die Brute-Force-Resistenz von bcrypt gegenüber MD5 für Passwort-Hashing? und Ergebnisse der Hash-Algorithmus-Leistungstests.

ol>