Bereinigen von Benutzerkennwörtern

Wie kann ich vom Benutzer bereitgestellte Kennwörter maskieren oder bereinigen, bevor ich sie hashe und in meiner Datenbank speichere?

Wenn PHP-Entwickler aus Sicherheitsgründen das Hashing von Benutzerpasswörtern in Betracht ziehen, denken sie häufig an diese Passwörter wie an andere vom Benutzer bereitgestellte Daten. Dieses Thema taucht häufig in PHP-Fragen zur Kennwortspeicherung auf. der Entwickler oft will das Passwort mit Funktionen wie reinigen escape_string()(in verschiedenen Iterationen) htmlspecialchars(), addslashes()und andere , bevor es Hashing und sie in der Datenbank zu speichern.

Sie sollten Passwörter, die Sie mit PHPs verwenden, password_hash()aus einer Reihe von Gründen niemals entkommen, kürzen oder einen anderen Bereinigungsmechanismus verwenden. Der größte Grund dafür ist, dass für eine zusätzliche Bereinigung des Passworts unnötiger zusätzlicher Code erforderlich ist.

Sie werden argumentieren (und Sie sehen es in jedem Beitrag, in dem Benutzerdaten zur Verwendung in Ihren Systemen akzeptiert werden), dass wir alle Benutzereingaben bereinigen sollten, und Sie wären für jede andere Information, die wir von unseren Benutzern akzeptieren, richtig. Passwörter sind unterschiedlich. Hashed-Passwörter können keine SQL-Injection-Bedrohung darstellen, da die Zeichenfolge vor dem Speichern in der Datenbank in Hash umgewandelt wird.

Durch das Hashing eines Kennworts wird sichergestellt, dass das Kennwort sicher in Ihrer Datenbank gespeichert wird. Die Hash-Funktion gibt Bytes keine besondere Bedeutung, daher ist aus Sicherheitsgründen keine Bereinigung ihrer Eingabe erforderlich

Wenn Sie den Mantras folgen, Benutzern zu erlauben, die gewünschten Passwörter / Phrasen zu verwenden , und Sie Passwörter nicht einschränken , indem Sie eine beliebige Länge, eine beliebige Anzahl von Leerzeichen und ein Hashing von Sonderzeichen zulassen, wird das Passwort / die Passphrase sicher, unabhängig davon, was darin enthalten ist das Passwort. Ab dem derzeit häufigsten Hash (Standardeinstellung) wird PASSWORD_BCRYPTdas Kennwort in eine 60 Zeichen breite Zeichenfolge umgewandelt, die ein zufälliges Salt zusammen mit den Informationen zum Hash-Kennwort und den Kosten (den algorithmischen Kosten für die Erstellung des Hashs) enthält:

Mit PASSWORD_BCRYPT werden neue Kennwort-Hashes mithilfe des CRYPT_BLOWFISH-Algorithmus erstellt. Dies führt immer zu einem Hash im Krypta-Format "$ 2y $", das immer 60 Zeichen breit ist.

Der Platzbedarf zum Speichern des Hashs kann sich ändern, da der Funktion verschiedene Hashing-Methoden hinzugefügt werden. Daher ist es immer besser, den Spaltentyp für den gespeicherten Hash wie VARCHAR(255)oder zu vergrößern TEXT.

Sie können eine vollständige SQL-Abfrage als Kennwort verwenden, die gehasht wird und von der SQL-Engine nicht ausgeführt werden kann, z.

SELECT * FROM `users`;

Könnte gehasht werden $2y$10$1tOKcWUWBW5gBka04tGMO.BH7gs/qjAHZsC5wyG0zmI2C.KgaqU5G

Mal sehen, wie sich verschiedene Desinfektionsmethoden auf das Passwort auswirken -

Das Passwort lautet I'm a "dessert topping" & a <floor wax>!(Am Ende des Passworts befinden sich 5 Leerzeichen, die hier nicht angezeigt werden.)

Wenn wir die folgenden Trimmmethoden anwenden, erhalten wir einige wild unterschiedliche Ergebnisse:

var_dump(trim($_POST['upassword']));
var_dump(htmlentities($_POST['upassword']));
var_dump(htmlspecialchars($_POST['upassword']));
var_dump(addslashes($_POST['upassword']));
var_dump(strip_tags($_POST['upassword']));

Ergebnisse:

string(40) "I'm a "dessert topping" & a <floor wax>!" // spaces at the end are missing
string(65) "I'm a &quot;dessert topping&quot; &amp; a &lt;floor wax&gt;!     " // double quotes, ampersand and braces have been changed
string(65) "I'm a &quot;dessert topping&quot; &amp; a &lt;floor wax&gt;!     " // same here
string(48) "I\'m a \"dessert topping\" & a <floor wax>!     " // escape characters have been added
string(34) "I'm a "dessert topping" & a !     " // looks like we have something missing

Was passiert, wenn wir diese senden password_hash()? Sie werden alle gehasht, genau wie bei der obigen Abfrage. Das Problem tritt auf, wenn Sie versuchen, das Kennwort zu überprüfen. Wenn wir eine oder mehrere dieser Methoden anwenden, müssen wir sie erneut anwenden, bevor wir sie vergleichen password_verify(). Folgendes würde fehlschlagen:

password_verify($_POST['upassword'], $hashed_password); // where $hashed_password comes from a database query

Sie müssten das veröffentlichte Kennwort über die von Ihnen gewählte Bereinigungsmethode ausführen, bevor Sie das Ergebnis bei der Kennwortüberprüfung verwenden können. Es ist eine unnötige Reihe von Schritten und wird den Hash nicht besser machen.

Verwenden Sie eine PHP-Version unter 5.5? Sie können das password_hash() Kompatibilitätspaket verwenden .

Sie sollten wirklich keine MD5-Passwort-Hashes verwenden .

Bevor Sie das Kennwort hashen, sollten Sie es wie in Abschnitt 4 von RFC 7613 beschrieben normalisieren . Bestimmtes:

2. Zusätzliche Zuordnungsregel: Alle Instanzen von Nicht-ASCII-Speicherplatz MÜSSEN dem ASCII-Speicherplatz (U + 0020) zugeordnet werden. Ein Nicht-ASCII-Raum ist ein beliebiger Unicode-Codepunkt mit einer allgemeinen Unicode-Kategorie von "Zs" (mit Ausnahme von U + 0020).

und:

4. Normalisierungsregel: Das Unicode-Normalisierungsformular C (NFC) MUSS auf alle Zeichen angewendet werden.

Dadurch wird sichergestellt, dass das Kennwort weiterhin akzeptiert wird, wenn der Benutzer dasselbe Kennwort eingibt, jedoch eine andere Eingabemethode verwendet.