Nettoyage des mots de passe utilisateur

Comment dois-je échapper ou nettoyer les mots de passe fournis par l'utilisateur avant de les hacher et de les stocker dans ma base de données?

Lorsque les développeurs PHP envisagent de hacher les mots de passe des utilisateurs à des fins de sécurité, ils ont souvent tendance à penser à ces mots de passe comme ils le feraient pour toute autre donnée fournie par l'utilisateur. Ce sujet revient souvent dans les questions PHP liées au stockage des mots de passe; le développeur souhaite souvent nettoyer le mot de passe à l'aide de fonctions telles que escape_string()(dans diverses itérations) htmlspecialchars(), addslashes()et d'autres avant de le hacher et de le stocker dans la base de données.

Vous ne devriez jamais échapper, couper ou utiliser tout autre mécanisme de nettoyage sur les mots de passe que vous hacherez avec PHP password_hash()pour un certain nombre de raisons, dont la plus importante est que le nettoyage supplémentaire du mot de passe nécessite du code supplémentaire inutile.

Vous argumenterez (et vous le verrez dans chaque article où les données utilisateur sont acceptées pour une utilisation dans vos systèmes) que nous devrions nettoyer toutes les entrées utilisateur et que vous auriez raison pour toutes les autres informations que nous acceptons de nos utilisateurs. Les mots de passe sont différents. Les mots de passe hachés ne peuvent pas offrir de menace d'injection SQL car la chaîne est transformée en hachage avant d'être stockée dans la base de données.

Le hachage d'un mot de passe consiste à rendre le mot de passe sûr pour le stocker dans votre base de données. La fonction de hachage ne donne aucune signification particulière à aucun octet, donc aucun nettoyage de son entrée n'est nécessaire pour des raisons de sécurité

Si vous suivez les mantras permettant aux utilisateurs d'utiliser les mots de passe / phrases qu'ils souhaitent et que vous ne limitez pas les mots de passe , autoriser n'importe quelle longueur, n'importe quel nombre d'espaces et tout hachage de caractères spéciaux rendra le mot de passe / phrase de passe sûr, peu importe ce qu'il contient le mot de passe. À l'heure actuelle, le hachage le plus courant (par défaut), PASSWORD_BCRYPTtransforme le mot de passe en une chaîne de 60 caractères de large contenant un sel aléatoire avec les informations de mot de passe hachées et un coût (le coût algorithmique de la création du hachage):

PASSWORD_BCRYPT est utilisé pour créer de nouveaux hachages de mot de passe à l'aide de l'algorithme CRYPT_BLOWFISH. Il en résultera toujours un hachage utilisant le format de cryptage «$ 2y $», qui est toujours large de 60 caractères.

L'espace requis pour stocker le hachage est sujet à changement à mesure que différentes méthodes de hachage sont ajoutées à la fonction, il est donc toujours préférable d'augmenter le type de colonne pour le hachage stocké, tel que VARCHAR(255)ou TEXT.

Vous pouvez utiliser une requête SQL complète comme mot de passe et elle serait hachée, ce qui la rendrait non exécutable par le moteur SQL, par exemple,

SELECT * FROM `users`;

Pourrait être haché $2y$10$1tOKcWUWBW5gBka04tGMO.BH7gs/qjAHZsC5wyG0zmI2C.KgaqU5G

Voyons comment différentes méthodes de désinfection affectent le mot de passe -

Le mot de passe est I'm a "dessert topping" & a <floor wax>!(Il y a 5 espaces à la fin du mot de passe qui ne sont pas affichés ici.)

Lorsque nous appliquons les méthodes de découpage suivantes, nous obtenons des résultats très différents:

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']));

Résultats:

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

Que se passe-t-il lorsque nous les envoyons password_hash()? Ils sont tous hachés, tout comme la requête ci-dessus. Le problème survient lorsque vous essayez de vérifier le mot de passe. Si nous employons une ou plusieurs de ces méthodes, nous devons les réutiliser avant de les comparer password_verify(). Ce qui suit échouerait:

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

Vous devrez exécuter le mot de passe publié via la méthode de nettoyage que vous avez choisie avant d'utiliser le résultat de cela dans la vérification du mot de passe. Il s'agit d'un ensemble d'étapes inutiles et n'améliorera pas le hachage.

Vous utilisez une version PHP inférieure à 5.5? Vous pouvez utiliser le password_hash() pack de compatibilité .

Vous ne devriez vraiment pas utiliser les hachages de mot de passe MD5 .

Avant de hacher le mot de passe, vous devez le normaliser comme décrit dans la section 4 de la RFC 7613 . En particulier:

2. Règle de mappage supplémentaire: toutes les instances d'espace non ASCII DOIVENT être mappées vers l'espace ASCII (U + 0020); un espace non ASCII est tout point de code Unicode ayant une catégorie générale Unicode de "Zs" (à l'exception de U + 0020).

et:

4. Règle de normalisation: la forme de normalisation Unicode C (NFC) DOIT être appliquée à tous les caractères.

Cela tente de garantir que si l'utilisateur tape le même mot de passe mais en utilisant une méthode d'entrée différente, le mot de passe doit toujours être accepté.