Ihre Option 1. ist eine schlechte Idee: Zusätzlich zu den von Ihnen angegebenen Gründen für Benutzererfahrung / Öffentlichkeitsarbeit geben Sie Angreifern ein Fenster, in dem sie die Token zum Zurücksetzen von Kennwörtern abfangen und jedes Konto auf Ihrem Server gefährden können. Es löst Ihr Problem auch nicht, wenn Sie auch nur einen Benutzer haben, der zu faul ist, sich anzumelden / sein Passwort zu aktualisieren.

Auf den ersten Blick scheinen mir sowohl 2. als auch 3. in Ordnung zu sein. Ihre Nummer 2 ist nicht weniger sicher als das, was Sie jetzt tun, aber 2. würde bedeuten, dass Sie das derzeit schwache Login für immer unterstützen müssen (oder etwas wie "Nach X Monaten löschen wir Ihr Passwort und zwingen Sie dazu) eine Wiederherstellung ", die die gewünschte Benutzertransparenz unterbricht. Ignorieren wir das also.

Betrachten wir den Fall, in dem sich Benutzer in der Datenbank befinden, die sich nie wieder anmelden werden. Sowohl mit 2. als auch mit 3. müssen Sie die aktuelle Hashing-Alge in Ihrer Codebasis für immer unterstützen, nur für den Fall, dass sie sich anmelden, aber mindestens 3. hat den Vorteil, dass sie (oder besser Sie) geschützt sind Offline-Brute-Force-Angriffe, falls Ihre Datenbank jemals gestohlen wird.

Da Sie die Spalte "Old Style Flag" für immer behalten müssen, tun Sie sich selbst einen Gefallen und machen Sie sie zu einem int kein bool , damit Sie, falls Sie Ihr Passwort-Hashing-Alg jemals erneut aktualisieren müssen, aufzeichnen können, auf welchem ​​ alten Stil sie sich befinden.

UPDATE: Eine sehr ähnliche Frage wurde hier gestellt und baut auf der Diskussion aus diesem Thread auf.

Wenn Sie Option 3 ausführen können, verstehe ich nicht, warum Sie die anderen überhaupt in Betracht ziehen würden. Es ist bei weitem die beste Option. Bei dieser Option wäre es mein Bauchgefühl, zwei verschiedene Salze zu verwenden, eines für den alten Algorithmus und eines für das neue mit bcrypt. Ich stelle mir eine Einrichtung wie diese vor:

1. Richten Sie Ihr neues Kennwortsystem so ein, wie Sie es heute tun würden.
2. Erstellen Sie eine neue separate Tabelle mit Feldern für Benutzername (oder ID), Hashing-Algorithmus (Name oder ID), Salt.
3. Überprüfen Sie beim Anmelden, ob der Benutzer einen Datensatz in der separaten Tabelle hat, und wenn ja, hacken Sie das Kennwort auf die alte Weise. Hashing dann das Ergebnis auf neue Weise und vergleiche es mit dem bcrypt-Hash. Wenn es übereinstimmt, salzen / hashen Sie das Passwort auf die neue Weise neu und löschen Sie den Datensatz aus der separaten Tabelle.
ol>

Der Nachteil ist, dass Sie das Passwort einige Male im Speicher behalten müssen Millisekunden länger (wen interessiert das?) und Sie haben die zusätzliche Tabellensuche bei jedem Login, so ziemlich für immer, bis entweder die separate Tabelle leer ist oder bis alte Konten so alt werden, dass Sie bereit sind, von ihnen zu verlangen, dass sie ihr Passwort selbst zurücksetzen.

Beachten Sie, dass Sie, wenn Ihr ALTES Schema mit Salz gehasht wird, das Schema Nr. 3 nur verwenden können, wenn Sie das Salz SEPARAT speichern.

Normalerweise wird das Salz zusammen mit dem Hash gespeichert. und Sie verwenden das Salz als Eingabe für die Hash-Funktion. Wenn Sie nicht genau dasselbe Salz verwenden, erhalten Sie eine völlig andere Ausgabe.

Wenn Sie newhash (oldsalt + oldhash, newsalt), dann Selbst wenn Sie das richtige Passwort haben, können Sie Oldhash nicht neu erstellen (da Sie kein Oldsalt haben) und Sie können den endgültigen Hash nicht generieren. Gleiches gilt für alle Parameter (z. B. hat bcrypt einen "Kosten" -Parameter - dieser muss beim Verschlüsseln festgelegt und in die Ausgabe eingebettet werden, damit das Kennwort überprüft werden kann).

AUCH : Wenn Sie, wie von anderen erwähnt, speichern, dass der Hash "alt" oder "neu" ist, sollten Sie stattdessen das "Schema" speichern - wobei z 0 ist das "alte" und 1 ist bcrypt (Hinweis, ich verwende nicht "neu" - es ist jetzt "neu", wird nicht für immer "neu" sein!). Ein üblicher Weg, dies zu tun, besteht darin, am Anfang des Hashs einen Marker zu haben (dies kann bereits der Fall sein!). bcrypt verwendet eines der folgenden Standardpräfixe: "$ 2a $", "$ 2b $", "$ 2x" oder "$ 2y $". Abhängig von den möglichen Ausgaben Ihres "alten" Algorithmus müssen Sie möglicherweise Ihr eigenes Präfix erstellen, um diese zu markieren, oder Sie können mit "alles, was nicht mit" $ "beginnt, ist der alte Algorithmus davonkommen.

Und schließlich, da Sie offensichtlich (zu Recht!) mit der Sicherheit der alten Passwörter befasst sind, würde ich vorschlagen, alle zu zwingen, ihr Passwort zu ändern, indem Sie ihnen Anweisungen per E-Mail mit einem Token senden (NICHT! SENDEN) Ein Link! Sie möchten nicht, dass Ihre Benutzer auf einen Link klicken! Sagen Sie ihnen einfach, dass sie sich an der üblichen Stelle anmelden sollen. Fragen Sie dann nach dem Token UND dem Passwort. Andernfalls kann jemand, der in der Vergangenheit ein Passwort gestohlen hat, das Passwort ändern und ein gültiges "neues" Passwort erhalten.

ENDLICH: Verfallsdatum - Wenn Kennwörter bis zu diesem Datum nicht geändert werden, sollten sie ungültig werden. Dieses Datum sollte in der E-Mail stehen und nicht zu weit in der Zukunft liegen (eine Woche? Hängt davon ab, wie lange Ihre Kunden brauchen, um zu antworten). Danach müssen sie die Prozeduren zum Zurücksetzen des Passworts durchlaufen.

Ich weiß nicht, wie Ihr Passwortkodierungsschema aussieht, aber wenn es nicht so schlimm ist, ist es wahrscheinlich, dass die Struktur des Passworts im alten und neuen Format unterschiedlich ist.

Ich habe bereits etwas gesehen So wie in einem alten BSD-System, als das System von einer herkömmlichen Kennwortkodierung zu einer sichereren geändert wurde. Die neue begann mit einer Zeichenfolge, die im alten Schema nicht vorhanden sein konnte. Jedes Mal, wenn ein Benutzer mit einem alten Kennwort angemeldet war, wurde sein Klartextkennwort mit der alten Methode überprüft und stillschweigend erneut gehasht und in der Kennwortdatenbank mit gespeichert die neue Methode. Nach einem Monat war kein altes Passwort in der Datenbank vorhanden, ohne dass der Endbenutzer etwas bemerkte.

Das würde irgendwo zwischen Ihrer zweiten und dritten Methode liegen.

Ich weiß das in einer realen Produktionswebsystem können die Dinge jetzt viel schlimmer sein, da Benutzer Wochen oder sogar Monate warten können, bevor sie wieder eine Verbindung herstellen. Aber (abhängig von der tatsächlichen Aktivität) kann es durch die Tatsache gemildert werden, dass ein Benutzer, der seit mehreren Monaten keine Verbindung mehr hergestellt hat, sein Passwort vergessen haben kann - oder Sie können ihm sagen, dass er es getan hat ... Das bedeutet, dass ich etwas warten würde länger hier wahrscheinlich 3 oder 6 Monate und nach dieser Zeit würde ich alle alten Passwörter auf einen verbotenen Wert zurücksetzen und den Benutzer zwingen, sein Passwort bei der nächsten Verbindung zurückzusetzen ... über den Bildschirm vergessenes Passwort .

Die schönen Dinge hier sind:

• transparent für normale Benutzer
• keine Änderung des Datenbankschemas - vorausgesetzt, das Kennwortfeld kann beide Stile akzeptieren

Der Nachteil ist, dass Sie gezwungen sind, beide Authentifizierungsmethoden und eine automatische Aktualisierung aller gleichzeitig zu implementieren Stil Passwort.

Sie haben die von Ihnen verwendete Sprache nicht erwähnt. Php hat Probleme mit verschiedenen Funktionen, die false zurückgeben sollten, wenn es in einigen Fällen true zurückgeben sollte, oder mit anderen Funktionen, die so klingen, als würden sie die Arbeit erledigen, aber nicht über die Logik verfügen, um tatsächlich die vollständig möglichen gültigen möglichen Eingaben zu verarbeiten > Aber dies ist der richtige Weg, um das zu tun, wovon Sie in PHP sprechen, auch wenn Sie kein PHP verwenden. Der High-Level-Code kann Ihnen einen Ausgangspunkt für die Codierung für Ihre Zwecke geben.

http://php.net/manual/en/function.password-needs-rehash.php

  $ password = 'rasmuslerdorf'; $ hash = '$ 2y $ 10 $ YCFsG6elYca568hBi2pZ0.3LDL5wjgxct1N8w / oLR / jfHsiQwCqTS'; // Der Kostenparameter kann sich im Laufe der Zeit ändern, wenn sich die Hardware verbessert options = array ('cost' = > 11); // Gespeicherten Hash anhand des Klartext-Passworts überprüfen (password_verify ($ password, $ hash)) {// Überprüfen Sie, ob ein neuerer Hashing-Algorithmus verfügbar ist // oder sich die Kosten geändert haben if (password_needs_rehash ($ hash, PASSWORD_DEFAULT, $ options)) {// Wenn ja, erstellen Sie einen neuen Hash und ersetzen Sie den alten $ newHash = password_hash ($ password, PASSWORD_DEFAULT, $ options); } // Benutzer anmelden}  

Was ich tun würde, wäre Ihre Nummer 2 mit dem, was mit einem int erwähnt wurde. Beim Lesen der Dokumentation zu PASSWORD_DEFAULT kann sich dies ändern, wenn bessere Algorithmen gefunden werden und diese aus Unsicherheitsgründen entfernt werden müssen, wenn PHP aktualisiert wird.

Informieren Sie die Benutzer über die Sicherheitslücken im alten Authentifizierungssystem und schlagen Sie vor, dass sie ihr Kennwort ändern / zurücksetzen, um das neue Authentifizierungssystem zu verwenden. Wenn einige Benutzer nach einer festgelegten Zeitspanne (auf die die Benutzer möglicherweise im "Kleingedruckten" irgendwo hingewiesen werden) ihr Kennwort noch nicht geändert / zurückgesetzt haben, deaktivieren Sie ihr Konto und senden Sie ihnen eine E-Mail mit Anweisungen aktiviere es erneut. Auf diese Weise haben Ihre regulären Benutzer das Gefühl, dass sie "aufgefordert" werden, ihr Passwort zu ändern, und nicht "aufgefordert" werden, ihr Passwort zu ändern. Daher ist es unwahrscheinlich, dass sie negativ auf die Anfrage reagieren, selbst wenn sie ihr Passwort ändern (was sie hoffentlich tun werden) , wenn Ihre Beratungs-E-Mail überzeugend genug ist) und Sie das alte Authentifizierungssystem für die wenigen Benutzer, die nie dazu gekommen sind, ihr Passwort zu ändern, nicht für immer unterstützen müssen.