Pourquoi : et comment : améliorer le hachage de mot de passe WordPress dans votre nouveau site Web

Vous avez donc terminé de peaufiner votre nouveau site WordPress brillant et vous êtes sur le point de le lancer dans le grand océan Internet. Bonne nouvelle. Très bientôt, Google reniflera tous les coins ouverts de votre site, un grand nombre de visiteurs satisfaits consommeront votre précieux contenu – et une armée de robots frapperont les murs de votre bateau toutes les deux heures de toutes leurs forces.

Nous vivons à une époque où le piratage n’est pas seulement une maladie rare, affectant ces vieux sites Web non entretenus qui sont oubliés dans ce grand océan. C’est quelque chose qui se produit quotidiennement sur des sites Web de toutes tailles, petits et grands.

Maintenant, si vous êtes assez courageux pour vérifier les journaux d’accès de vos sites Web en direct, vous trouverez plus d’une centaine de tentatives aléatoires de connexion à votre tableau de bord WordPress. Qui ferait ça? Que cherchent-ils? C’est probablement quelqu’un – personne ou bot – qui recherche ce fichier de cette version spécifique de ce plugin qui contient un exploit connu juteux. Ou ils recherchent une erreur de configuration ou une faille de sécurité que vous avez peut-être négligée dans votre build.

Avez-vous considéré que le piratage était une réelle possibilité? Non seulement en disant à haute voix « Tous les sites Web peuvent être piratés », mais en réfléchissant à ce que vous offrez et à ce que vous pouvez faire si une personne malveillante a accès aux données de votre site Web.

La plupart des gens ne remettent pas en question la sécurité du hachage de mot de passe utilisé dans leur site Web WordPress. Après tout, il existe une énorme communauté qui améliore et s’occupe de la base de code WordPress, n’est-ce pas? Malheureusement, la manière WordPress de hacher vos mots de passe n’est, par défaut, pas aussi forte qu’elle le devrait. Et il y a une raison à cela.

Portabilité

WordPress adore se vanter de l’un de ses points forts; être capable de fonctionner sur (presque) tous les serveurs, petits ou grands, pleins de ressources ou sans ressources, modernes ou anciens. Par souci de compatibilité avec les anciennes versions de PHP, la configuration par défaut de WordPress repose sur le hachage de mot de passe MD5 salé depuis 2008. Et, ne vous méprenez pas, c’était un bon moyen de hacher les mots de passe il y a 12 ans.

Avec la croissance exponentielle du calcul au cours de la dernière décennie, compter sur MD5 pour hacher votre mot de passe à ce stade est aussi sûr que de garder vos clés de maison sous le tapis avant. Ce n’est pas une bonne idée, comme peut en témoigner quiconque a déjà joué à Maniac Mansion.

Alors, qu’est-ce que MD5 exactement? Pourquoi n’est-il pas fiable pour le hachage des mots de passe? Et comment cela change-t-il?

Quel hachage WordPress utilise-t-il pour les mots de passe?

Jusqu’à la sortie de la version 2.5, WordPress utilisait simplement MD5 pour hacher tous les mots de passe de l’utilisateur. C’était loin d’être idéal pour de nombreuses raisons; le plus important étant la possibilité qu’avoir des hachages MD5 simples permette à un attaquant d’utiliser Rainbow Tables pour éviter d’utiliser la puissance de calcul pour deviner le mot de passe d’origine.

Avec le lancement de la version 2.5 en 2008, la bibliothèque phpass a été incluse pour introduire le hachage salé qui est configuré par défaut pour saler l’algorithme MD5. Cela signifie que Rainbow Tables ne fera plus peur à notre précieuse base de données d’utilisateurs.

Si vous n’êtes pas familier avec le salage de mot de passe – non, malheureusement, cela ne rend pas nos pommes de terre rissolées plus savoureuses – il s’agit de générer une chaîne aléatoire et de l’ajouter à votre vrai mot de passe avant qu’il ne soit haché.

Encore confus? Ce n’est pas un concept facile à comprendre. C’est pourquoi nous apportons des exemples à la rescousse !

Enfin, les 22 derniers caractères seront le résultat du hachage « ananas mPQS4gF8» [B] fois en utilisant [$P$] algorithme.

Si efficacement, WordPress a évolué en faisant un simple md5 («ananas»), pour ajouter un peu plus de ressources de calcul et d’aléatoire au résultat final. Il s’agissait de garantir que deviner le mot de passe d’origine n’impliquera pas simplement de regarder le résultat haché.

Salt augmente le temps nécessaire pour déchiffrer un mot de passe et oblige probablement tout attaquant à dépenser ces millisecondes supplémentaires pour appliquer le sel à l’algorithme. Mais le salage n’est qu’une petite bosse sur la route pour tout mot de passe qui utilise moins de 8 caractères ou qui est vulnérable aux attaques par dictionnaire.

Personne ne devinera ce mot de passe de si tôt.

Que pouvons-nous y faire?

Vous l’avez peut-être deviné : je ne vous raconterais pas toute cette histoire effrayante si nous n’avions pas de super-héros pour protéger nos mots de passe WordPress faibles et pleins de bosses.

Si nous n’avons pas envie de nous éloigner trop du chemin WordPress établi, PHPass nous permet également d’utiliser l’un des trois algorithmes de hachage différents: MD5, DES ou Blowfish.

Par défaut, WordPress applique le hachage MD5 salé pour assurer la compatibilité avec les anciennes versions de PHP. Il utilise PHPass en mode «portable» pour permettre de migrer l’instance WordPress entre les serveurs sans avoir à se soucier trop de la version PHP que le serveur exécute. Si nous choisissons de supprimer la «portabilité» de PHPass, nous pouvons utiliser DES ou Blowfish; mais si nous le faisons, nous sommes «limités» à toujours utiliser une version PHP 5.3 ou ultérieure – ce que nous devrions être de toute façon.

Quelles sont nos options?

Option 1 : Continuez à utiliser PHPass et changez le hachage en blowfish; la plus difficile à déchiffrer de nos trois méthodes de hachage.

Ce n’est pas le but de cet article d’invalider l’approche adoptée par les dieux tout puissants de WordPress. Vous pouvez facilement augmenter votre force de hachage en modifiant quelques paramètres lors de l’instanciation de la bibliothèque PHPass via la classe PasswordHash.

Par défaut, WordPress crée un objet PasswordHash en utilisant l’appel suivant:

nouveau PasswordHash (8, vrai);

Le premier paramètre de ce constructeur est le nombre d’interactions que nous allons utiliser pour hacher le mot de passe; ou en d’autres termes: combien de temps notre précieux processeur devrait passer à hacher le mot de passe. Plus nous y consacrons de temps, plus un utilisateur non autorisé aura besoin de temps pour reproduire le même processus. Le deuxième paramètre indique si l’instance est portable ou non, ce qui se traduit par la prise en charge des anciennes versions de PHP ou non.

Donc, ce que nous essayons de réaliser ici, c’est de nous retrouver avec un constructeur comme celui-ci :

nouveau PasswordHash (16, faux);

Tout d’abord, nous augmentons les interactions de 8 à 16. Pourquoi? Aucune raison spécifique à part le fait de suivre l’approche Drupal pour aller avec 16 et de tenir compte de l’augmentation de la loi de Moore de la puissance de traitement à 1,5 par an. Techniquement, vous pouvez choisir n’importe quelle valeur entre 4 et 31, mais nous devrions viser un équilibre doux entre la sécurité et les performances du serveur.

Le deuxième paramètre désactive le composant de portabilité de la bibliothèque et dit essentiellement à PHPass d’utiliser BLOWFISH ou DES si disponible.

«Mais, Sergio. Où et quand devrions-nous mettre à jour notre code pour remplacer les instances PasswordHash que WordPress est en train de créer? » Je vous entends demander. Bonne question lecteur apprécié. WordPress n’a pas documenté de manière officielle de le faire, mais il nous donne quelques indices sur la façon dont nous pourrions résoudre ce problème. La vie est pleine de choix ! Comme c’est excitant !

Si vous jetez un coup d’œil furtif aux fonctions de base impliquées dans le hachage du mot de passe de l’utilisateur, wp_hash_password, vous remarquerez peut-être que la fonction est enfichable. Cela signifie que WordPress ne créera la fonction que si aucun autre plugin ne l’a encore créée. Il recherchera également un objet global $ wp_hasher contenant une méthode HashPassword.

Approche 1 : définissez le $ wp_hasher global au début de votre code.

C’est probablement mon approche préférée parmi les deux car vous aurez besoin d’écrire moins de code (et nous, les développeurs, sommes paresseux) et cela fonctionne pour plus que les deux principales fonctions impliquées dans le hachage de mot de passe.

Vous pouvez choisir d’instancier la variable $ wp_hasher dans un hook init précoce ou même dans votre fichier wp-config.php. Quelle que soit la méthode que vous choisissez, elle devrait ressembler à quelque chose de similaire à ceci :

global $ wp_hasher;

require_once ABSPATH. WPINC. «/Class-phpass.php»;

$ wp_hasher = nouveau PasswordHash (16, faux);

Et c’est tout ! Prenez un mouchoir, évacuez votre sueur, allongez-vous et détendez-vous. Vous venez de renforcer la sécurité des mots de passe de vos utilisateurs.

Approche 2 : Définissez les fonctions enfichables dans un nouveau plugin.

Vous n’êtes pas un fan des variables globales, c’est juste, et pas de soucis, WordPress sait comment épargner un peu d’amour à toutes sortes de créatures de développeurs.

La logique de base derrière le hachage et la vérification des mots de passe est exécutée par les fonctions wp_hash_password et wp_check_password. Heureusement pour nous, les deux fonctions sont enfichables ! Il vous suffit donc de créer un nouveau plugin pour définir ces deux fonctions avant que WordPress ne le fasse, comme un vieux film western, le tirage le plus rapide l’emporte.

Je n’entrerai pas dans tous les détails sur la création d’un plugin WordPress. Je suppose que vous avez un nouveau plugin incroyable prêt à être rempli de logique; vous devez y trouver une place pour définir les deux fonctions mentionnées ci-dessus avec quelque chose qui ressemble à ceci :

if ( ! function_exists (‘wp_hash_password’)) :

require_once ABSPATH. WPINC. «/Class-phpass.php»;

$ wp_hasher = nouveau PasswordHash (16, faux);

return $ wp_hasher-> HashPassword (trim ($ password));

fin si;

if ( ! function_exists (‘wp_check_password’)) :

[…]

require_once ABSPATH. WPINC. «/Class-phpass.php»;

$ wp_hasher = nouveau PasswordHash (16, faux);

$ check = $ wp_hasher-> CheckPassword ($ password, $ hash);

return apply_filters (‘check_password’, $ check, $ password, $ hash, $ user_id);

fin si;

Option 2 : Passez au nouveau PHP natif password_hash () introduit dans PHP 5.5.

Saviez-vous que lorsque nous appliquons la méthode blowfish de la bibliothèque PHPass WordPress, nous utilisons effectivement la fonction PHP native crypt () avec certains sels générés par la bibliothèque PHPass elle-même? Et «pourquoi est-ce important?», Pourriez-vous demander.

Pour répondre à ces questions, admettons d’abord que la fonction de cryptage a un objectif plus large que le simple hachage de mot de passe. Vous voudrez peut-être hacher une chaîne où, même si elle est compromise, elle n’est pas critique pour la sécurité de votre application. Un exemple pourrait être l’utilisation d’un lien d’activation de compte unique que vous envoyez à vos utilisateurs.

Parce que la fonction crypt est devenue de plus en plus populaire en tant que système de hachage de mot de passe, à partir de la version 5.5, PHP a décidé de donner à la fonction crypt un wrapper formel spécifiquement destiné à être utilisé comme système de hachage de mot de passe : password_hash ()

Donc, utiliser password_hash () revient au même que choisir le bon algorithme, avec les bons sels pour la fonction crypt ().

Une autre différence entre password_hash () et l’utilisation simple de crypt () est que password_hash () vous permet de passer l’argument PASSWORD_DEFAULT pour laisser le système choisir le meilleur algorithme de hachage disponible pour vous. Cela signifie qu’à un moment donné dans le futur, si votre version PHP utilise Blowfish, elle peut automatiquement passer à un algorithme plus puissant sans intervention du développeur.

Pour passer de la bibliothèque PHPass à une logique password_hash – identique à l’option précédente – vous pouvez créer votre propre classe PasswordHash et l’affecter à la variable globale $ wp_hasher ou, si vous êtes uniquement intéressé par l’amélioration des fonctions liées à la génération de mot de passe, vous pouvez remplacer les fonctions enfichables wp_hash_password et wp_check_password.

Étant donné que l’application de la logique password_hash () est légèrement plus complexe que la réutilisation des fonctions principales de WordPress, je vous suggère de regarder deux bons exemples que j’ai trouvés lors de la recherche sur ce sujet. Le premier est le hachage de mot de passe PHP natif et l’autre est wp-password-bcrypt. Les deux plugins essaient de garder la logique rétro-compatible avec la logique PHPass; Ainsi, si vous décidez de mettre à niveau le hachage du mot de passe alors que des utilisateurs utilisent déjà votre application, vous pouvez le faire de manière transparente sans affecter l’expérience de votre utilisateur.

Conclusion

L’utilisation de password_hash finira par passer à un meilleur algorithme de hachage lorsque quelque chose de meilleur sera disponible. Il est également possible que WordPress fasse la même chose au fil du temps.

Il est préférable de choisir l’intégration avec laquelle vous vous sentez le plus à l’aise et de ne pas regarder en arrière. Cela vous aidera à mieux dormir la nuit.

Tags: