Sie haben hier widersprüchliche Anforderungen. Die Kompatibilitätsanforderungen zwingen Sie dazu, die alten Hashes beizubehalten. Die Sicherheitsanforderungen zwingen Sie, sie fallen zu lassen. Hier müssen Sie entscheiden, welche Anforderungen erfüllt werden sollen.

Wenn Sie die Abwärtskompatibilität beibehalten möchten, versuchen Sie, das Beste aus einer schlechten Situation herauszuholen:

• Der alte und der neue Hash sollten in verschiedenen Tabellen gespeichert werden, und der von der Webanwendung verwendete Datenbankbenutzer sollte keinen Lesezugriff auf den alten Hash haben. Verwenden Sie hierfür Tabellen- und / oder Spaltenberechtigungen.
• Wenn Sie die alte Anwendung nicht mehr benötigen, löschen Sie die Tabelle mit dem alten Hash. Ashley Madison ist zu diesem Zeitpunkt bekanntermaßen gescheitert - sie haben ein Upgrade auf bcrypt durchgeführt und dann aus irgendeinem idiotischen Grund die alten MD5-Hashes in der Datenbank herumliegen lassen. Als die Datenbank durchgesickert ist, hat diese ausgefallene Verschlüsselung nicht viel geholfen ...

Oder alternativ, wenn Sie keine Angst haben, ein bisschen Chaos zu verursachen:

• Lass die alten Hashes fallen. Fügen Sie in der neuen Anwendung die Option "Temporäres Kennwort für alte Anwendung erstellen" hinzu. Sie erhalten ein langes, zufälliges Passwort, das auf die alte Weise gehasht und nur X Minuten in der Datenbank gespeichert wird. Der Benutzer kann sich dann bei der alten Anwendung anmelden, und das Kennwort wird automatisch gelöscht.

Gibt es eine sichere Möglichkeit, unserer Authentifizierungsdatenbank Salz (und Pfeffer) hinzuzufügen, während die Fähigkeit der alten Anwendung zur Authentifizierung von Benutzern erhalten bleibt?

Ja, dies ist möglich. Im Folgenden finden Sie allgemeine Implementierungsanweisungen. Die grundlegende Technik besteht darin, alle Kennwörter zu hashen und dann die Verbindung zwischen dem Client und dem Legacy-Server mit MITM durchzuführen, um das nicht gehashte Passwort durch ein Hash-Passwort zu ersetzen. Beachten Sie, dass Sie einen Roll-out-Plan erstellen müssen. Wenn Sie Schritt 1 in der Produktion blind ausführen, wird alles kaputt gehen.

Schritt 1: Alle vorhandenen Kennwörter salzen und das Salz dann irgendwo speichern. Überschreiben Sie das Kennwortfeld der Legacy-Datenbank mit dem gesalzenen Kennwort.

Schritt 2: Erstellen Sie einen Shim. Der Shim akzeptiert identische Parameter wie die Legacy-APIs.
Wenn die Legacy-API wie folgt implementiert ist:

  LegacyDoStuff (Benutzername, Kennwort, Argument) {if (! VerifyCredentials (Benutzername, Passwort)) return AuthenticationError (); Ergebnis = DoStuff (Argument); Ergebnis zurückgeben;}  

Die neue API wird implementiert als:

  NewDoStuff (Benutzername, Passwort, Argument) {hashedpassword = DoHash (Passwort + getSalt (Benutzername) )) LegacyDoStuff (Benutzername, Hash-Passwort, Argument) zurückgeben;}  

Schritt 3: Richten Sie den Legacy-Client auf den Shim anstatt auf den Hauptserver (oder gleichwertig) Verschieben Sie den Legacy-Server auf eine neue IP / DNS-Adresse und setzen Sie die Unterlegscheibe auf die alte IP / DNS-Adresse.

Mit diesem Ansatz können Sie die Interna des Legacy-Codes als Black Box behandeln, aber es erfordert, dass Sie sich der öffentlichen Oberfläche des Legacy-Codes bewusst sind, da Ihr Shim Anforderungen / Antworten zwischen dem Client und dem Legacy-Server senden muss.

Bei diesem Ansatz wird im Gegensatz zu den in anderen Antworten beschriebenen Ansätzen das Speichern des alten Kennworts vollständig vermieden. Dieser Ansatz ist jedoch viel schwieriger durchzuführen und führt mit größerer Wahrscheinlichkeit zu Fehlern.

Gibt es eine sichere Möglichkeit, unserer Authentifizierungsdatenbank Salz (und Pfeffer) hinzuzufügen, während die alte Anwendung weiterhin Benutzer authentifizieren kann?

Nein. Der Grund für das Versalzen und Hashing von Passwörtern besteht darin, dass die Angreifer-Passwörter für den Angreifer nicht zugänglich sind, wenn die Benutzerdatenbank gehackt / durchgesickert / kompromittiert wird (siehe Was bringt das Hashing von Passwörtern?). In der von Ihnen beschriebenen Lösung werden die Kennwörter der Benutzer weiterhin in der Benutzerdatenbank in einer benachbarten Spalte im Klartext gespeichert. Dies macht den Zweck des Salzens und Hashens von Passwörtern vollständig zunichte.

Natürlich muss die aktuelle Tabelle erhalten bleiben, damit die alte Anwendung funktionieren kann.

Fügen Sie möglicherweise eine neue Tabelle mit gesalzenen + gepfefferten Hashes hinzu, damit die neue Anwendung sie verwenden kann, und dann:

• Machen Sie die alte Tabelle für die neue Anwendung unzugänglich!
• Aktualisieren Sie beide Tabellen, wenn Sie das Kennwort eines Benutzers aktualisieren.
• Fordern Sie alle Benutzer des neuen Systems auf, ihr Kennwort zu aktualisieren / zurückzusetzen.
• In der neuen Tabelle kann eine Kopie gespeichert werden Der alte Hash wird zunächst aktualisiert und dann ordnungsgemäß gehasht, wenn der Benutzer sein Kennwort aktualisiert.

Dies setzt voraus, dass das Kennwortkontrollsystem von einem der Inhaltssysteme getrennt ist.

Dies bedeutet, dass eine Sicherheitsanfälligkeit im neuen System nicht auf die alten Hashes zugreifen kann (nach der Migration). Die Datenbank kann eine Sicherheitsanfälligkeit aufweisen, die es den Datenbankanmeldeinformationen des neuen Systems ermöglicht, auf eine Tabelle zuzugreifen, die sie nicht sollte. Dies ist jedoch viel weniger wahrscheinlich als bei Ihrer neuen Anwendung mit einer Sicherheitsanfälligkeit.

1. Fügen Sie zwei neue Spalten hinzu, eine Salt-Spalte und eine neue Hash-Spalte, zunächst null.
2. Wenn eine Authentifizierungsanforderung eingeht, überprüfen Sie das Salt-Feld.
3. Wenn das Feld einen Wert hat, gibt es einen neuen Hash, dem Pfeffer und Salz hinzugefügt wurden. Gehen Sie entsprechend vor.
4. Wenn nicht, handelt es sich um einen Hash im alten Stil. Überprüfen Sie mit dem alten Mechanismus. Vorausgesetzt, es ist erfolgreich, haben Sie jetzt das Klartext-Passwort aus der ursprünglichen Anfrage. Wenn Sie ein Salz generieren und speichern, haben Sie jetzt alles, was Sie zum Berechnen und Speichern eines neuen Hash benötigen. Das Legacy-System weiß nichts davon, daher kann es nur das neue System. (Es wäre besser gewesen, wenn sich kein System damit befassen müsste, aber den Job an die Datenbank selbst delegieren könnte. Das neue System kann, das alte System nicht.)
ol>

Schließlich auch Jeder hat sich mindestens einmal angemeldet und seine Hashes transparent aktualisiert (es sind keine NULL-Salze mehr in der Tabelle), oder die einzigen, die noch übrig sind, sind diejenigen, die sich überhaupt nicht anmelden.

Setzen Sie das ungesalzene und Gesalzene Hashes direkt nebeneinander in der Tabelle veranschaulichen nur die Tatsache, dass die Verwendung von Best Practices im neuen System unter Sicherheitsgesichtspunkten weiterhin irrelevant ist, solange das Altsystem weiterhin verwendet wird.

Ja, das ist möglich.

Verwenden Sie in der neuen Anwendung einen Hash-of-Hash-Doppel-Hash-Algorithmus, z. B.: Schritt 1: Hash das gesalzene Passwort, Schritt 2: Hash das Hash (kein Salz)

Ansatz 1:

Entwickeln Sie eine einfache eigenständige App, die ein Kennwort verwendet und den gesalzenen Hash eines Benutzerkennworts generiert und anzeigt

Bitten Sie alle internen Benutzer, ihr Kennwort in der alten Anwendung auf die Ausgabe der eigenständigen App zurückzusetzen, und verwenden Sie von nun an bei der Anmeldung den Vorgang der Eingabe des Kennworts in die Standalone-App zum Generieren des Passwort-Hashs, der in den Anmeldebildschirm eingegeben wird. Die Ausgabe könnte in die Zwischenablage generiert werden, um visuelle Hinweise zu vermeiden.

Ansatz 2

Wenn Sie die Datenbank irgendwie verwenden können, führen Sie den Hash von Hash in ein die Datenbank. Machen Sie Schritt 2 zum gesalzenen Hash und speichern Sie nur diesen.

Bearbeiten, um Folgendes zu verdeutlichen: Beispiel: Wenn Sie eine Datenbank verwenden, die benutzerdefinierte Operatoren unterstützt, deklarieren Sie einen benutzerdefinierten Gleichheitsoperator in einer Spalte, in der der newsaltedhash (oldhash) gespeichert ist. als benutzerdefinierter Typ. Wenn die App eine Abfrage nach einer Zeile mit übereinstimmendem Benutzernamen und altem Hash ausführt, führt der benutzerdefinierte Operator einen Newsalted-Hash für den eingehenden Hash aus und führt den Vergleich durch. Das Zurücksetzen des Kennworts erfolgt durch Einfügetrigger.

Zusammenfassung: In beiden Szenarien funktionieren Ihre Apps wie ursprünglich entworfen und der gespeicherte Kennwort-Hash ist ein Hash + Salt-Double-Hash (Pepper optional in beiden Implementierungen hinzugefügt)

Diese Antwort ist inspiriert von Brians Antwort und Franks Ansatz Nr. 1, die beide im Wesentlichen den neuen gesalzenen Hash als Passwort für die alte Anwendung verwenden. Da eine Anwendung das Salt aus der Datenbank abrufen muss, um den Hash zu generieren, wäre es einfacher und sicherer, wenn diese Anwendung den Benutzer authentifiziert und ein vollständig separates zufälliges Token als Kennwort für das alte System verwendet. P. >

Schritt 1: Wählen Sie eine moderne Passwort-Hashing-Lösung.

Wählen Sie eine gut unterstützte Passwort-Hashing-Bibliothek für die Sprache Ihrer Wahl aus, die das Generieren von sicherem Salt für Sie übernehmen soll. Es wird wahrscheinlich eine einzelne Zeichenfolge ausgegeben, die den Hash, das Salt und andere Parameter enthält, die zur Überprüfung des Kennworts erforderlich sind, sodass Sie in Zukunft schrittweise einen stärkeren Algorithmus einführen können. Verwenden Sie im Fall von PHP beispielsweise die integrierten Kennwort-Hashing-Funktionen.

Erstellen Sie eine neue Spalte in der Datenbank, um diese einzelne Zeichenfolge zu speichern. Eine Möglichkeit, dies zunächst zu füllen, besteht darin, NewHashFunction (OldStoredHash) zu berechnen und dann NewVerifyFunction (NewStoredHash, OldHashFunction (UserEnteredPassword)) auszuführen. Es gibt viele Diskussionen darüber, und es macht keinen Unterschied zum Rest dieser Antwort.

Schritt 2: Leere die alte Passwortspalte

Lösche alle dauerhaft alte unsichere Hashes, aber lassen Sie die Spalte nicht fallen. Zu diesem Zeitpunkt kann sich niemand bei der alten Anwendung anmelden, daher müssen wir das beheben ...

Schritt 3: Erstellen Sie ein Tool, um sich bei der alten Anwendung anzumelden.

Erstellen Sie eine Seite in Ihrer neuen Anwendung (wo der Benutzer bereits authentifiziert ist) oder einer eigenständigen Seite (die den Benutzer mithilfe der neuen Kennwortbibliothek authentifiziert), die Folgendes ausführt:

• Erzeugt ein langes zufälliges Kennwort
• Speichert den ungesalzenen Hash dieses zufälligen Passworts in der alten Passwortspalte für den authentifizierten Benutzer
• Zeigt dem Benutzer entweder das Kennwort zur Eingabe in die alte Anwendung an oder sendet es direkt, um den Benutzer automatisch anzumelden.

Beachten Sie, dass dieses zufällige Kennwort nicht gespeichert werden muss Überall, denn wenn sich der Benutzer erneut anmelden möchte, kann er einfach ein neues generieren.

Schritt 4: Machen Sie es sicherer, indem Sie das Zeitlimit für die Token überschreiten.

Die zufälligen Kennwörter sind Es ist bestimmt viel stärker als die meisten Benutzer, wenn sie keinen Passwort-Manager verwendet hätten. Sie werden jedoch weiterhin ungesalzen gespeichert und verwenden wahrscheinlich einen schnellen Hash. Es besteht auch das Risiko, dass das Passwort irgendwo kopiert wird, wenn es dem Benutzer angezeigt wird. Wir können beide Angriffe erheblich erschweren, indem wir nur die zufälligen Passwörter für einen kurzen Zeitraum gültig haben.

Fügen Sie der Datenbank eine zusätzliche Spalte für das "Ablaufdatum des zufälligen Kennworts" hinzu. Dies kann sehr kurz sein, wenn Sie sich automatisch anmelden, und einige Minuten, wenn der Benutzer das Kennwort selbst eingeben muss. Ein geplanter Job sollte dann einmal pro Minute ausgeführt werden und das alte Kennwortfeld für alle abgelaufenen Zeilen leeren.

Fügen Sie der Benutzertabelle als Pat des Upgrades eine Spalte hinzu, die angibt, ob das Konto aktualisiert wurde oder nicht. Wenn dies nicht der Fall ist, verwenden Sie den alten Code, um den Hash zu generieren und zu überprüfen. Wenn dies in Ordnung ist, generieren Sie das Salt und den neuen Hash und aktualisieren Sie den Benutzerdatensatz auf den neuen Hash Salt und setzen Sie das Flag Upgraded.

Wenn das Flag Upgraded bei der Anmeldung gesetzt ist, verwenden Sie den neuen Code Um das Salz zu lesen, machen Sie den Hash und überprüfen Sie das.

Das Speichern gesalzener Passwörter ist soooooooo 1995. Daher sollten Sie (wenn nichts Besseres möglich ist) mindestens einen gesalzenen Hash mit vielen Iterationen des Hash speichern. Dies ist tatsächlich weniger problematisch als Sie denken.

Ein Problem bei diesem Schema ist, dass Sie nicht wissen, wie viele Iterationen ausreichen, und wenn Computer schneller werden, benötigen Sie möglicherweise mehr. Zu viel Hashing ist jedoch sehr teuer ... insbesondere für eine große Benutzerdatenbank. Wie kann man das lösen?

Die häufig angewandte Lösung für diese Frage ist gleichzeitig die Lösung für Ihr primäres Problem.

Um dies zu berücksichtigen Wenn Sie die CPU-Leistung (oder wirklich die GPU-Leistung) erhöhen, fügen Sie eine weitere Spalte mit der Anzahl der Iterationen hinzu. Hin und wieder fügen Sie einem Benutzer eine Iteration hinzu (z. B. 5% zufällige Chance bei jeder Anmeldung). Dies ist sehr wenig Arbeit, da Sie nur einen zusätzlichen Hash ausführen müssen. Aktualisieren Sie sowohl die Anzahl als auch den gespeicherten Hash.

Nun muss erkannt werden, dass ein Hash-Passwort immer noch nur ein Passwort ist. Es ist ein bisschen "unlesbar", aber es ist immer noch nur ein Passwort, sonst nichts. Niemand hindert Sie daran, das zu salzen und es erneut zu hashen. Hasch es sogar oft. Kein Schaden angerichtet.

Wenn Ihre Authentifizierungsschicht eine Zeile aus der Datenbank abruft, in der die Hash-Anzahl Null ist, weiß sie, dass dies ein "alter" Eintrag ist, bei dem das Kennwort nicht gesalzen wurde (dies ist der Fall) null zusätzliche Hash-Runden). Also ... salzen Sie es, hacken Sie es tausendmal und speichern Sie 1000 für die Hash-Anzahl sowie den gesalzenen Hash. Fertig.

Die Anmeldeprozedur wäre also ungefähr so ​​(im Pseudocode):

  hash_entered = H (password_entered); [hash, count] = sql_query (SELECT WHERE Benutzername = blah); if (count == 0) {login_success = compare (hash_entered, hash); für (i = 0; i < 1000; ++ i) Hash = H (Hash); sql_query (UPDATE Hash = Hash, Anzahl = 1000); return login_success;} else {für (i = 0; i < count; ++ i) hash_entered = H (hash_entered);
login_success = compare (hash_entered, hash); if (zufällig (100) < = 5) {Hash = H (Hash); sql_query (UPDATE Hash = Hash, Anzahl = Anzahl + 1); } return login_success;}