DevelopmentComparatif
WordPress, Django ou Rails : choisir selon le projet
Comparez WordPress, Django et Ruby on Rails pour un site éditorial ou une application : publication, règles métier, compétences et maintenance.
DevelopmentGuide pratique
Hachage WordPress : bcrypt, anciens mots de passe et migration
Comprendre bcrypt dans WordPress, reconnaître les anciens formats et vérifier une intégration sans fragiliser la connexion des utilisateurs.
LA RÉPONSE UTILE
Depuis WordPress 6.8, les mots de passe des utilisateurs sont hachés par défaut avec bcrypt, précédé d’un préhachage SHA-384. Les anciens formats restent vérifiables. Utilisez les fonctions WordPress plutôt que de reproduire cet algorithme dans votre application.
- Le hachage n’est pas un chiffrement réversible.
- Un ancien hash présent en base ne signifie pas que la mise à jour a échoué.
- La compatibilité d’un connecteur se vérifie sur plusieurs générations de comptes.
Quel algorithme WordPress utilise-t-il aujourd’hui ?
Le changement important remonte à WordPress 6.8 : le mécanisme par défaut des mots de passe utilisateurs est passé de phpass portable à bcrypt. Un prétraitement SHA-384 évite que la limite de longueur de bcrypt ne tronque simplement un mot de passe long. Le format WordPress porte un préfixe distinct, généralement $wp$2y$ avec les réglages par défaut.
Cette description concerne le comportement du cœur, pas toutes les installations imaginables. Une extension peut remplacer ou filtrer le traitement. Les mots de passe d’application et les clés de récupération suivent d’autres mécanismes ; il serait trompeur de dire que toutes les données secrètes de WordPress utilisent bcrypt.
Pourquoi retrouve-t-on encore MD5 ou phpass ?
WordPress conserve des chemins de vérification pour les anciens formats. Lorsqu’un utilisateur se connecte après la mise à jour, ou change son mot de passe, le flux normal peut réenregistrer un hash adapté au mécanisme actuel. La migration n’exige donc pas une réinitialisation générale uniquement à cause de ce changement.
Un ancien tutoriel qui conseille de modifier class-phpass.php ne constitue plus une méthode de migration appropriée. Modifier le cœur introduit une dépendance fragile aux mises à jour. Et remplacer un hash existant par un nouveau hash de ce hash ne recrée pas le mot de passe d’origine.
| Observation | Interprétation prudente | Action recommandée |
|---|---|---|
| Préfixe $wp$2y$ | Format bcrypt WordPress par défaut | Vérifier avec l’API WordPress |
| Préfixe $P$ | Format phpass historique possible | Préserver la compatibilité pendant la transition |
| Chaîne courte de type MD5 | Format ancien potentiellement conservé | Ne pas le choisir pour les nouveaux mots de passe |
Les fonctions à employer dans une intégration
wp_hash_password() produit un hash et wp_check_password() vérifie un secret contre un hash existant. Appeler directement password_verify() sur une valeur $wp… sans son traitement WordPress peut échouer : le préfixe et le préhachage font partie du format. Une comparaison directe entre deux nouveaux hashes n’est pas une vérification de mot de passe.
Ne recréez pas non plus un système de connexion complet autour d’une simple fonction de vérification. L’authentification comprend la limitation des tentatives, les cookies de session, les autorisations, les extensions et les éventuels facteurs supplémentaires. Pour une application séparée, partez du mécanisme d’authentification supporté plutôt que d’exposer la table des utilisateurs.
Une vérification de migration utile
Sur une copie de préproduction sans données réelles inutiles, préparez un compte créé avant la mise à jour et un compte créé après. Vérifiez une connexion correcte, un mot de passe erroné, la récupération du compte et l’intégration qui consomme l’authentification. Contrôlez aussi qu’aucun mot de passe ni hash complet ne se retrouve dans les journaux.
Conservez une sauvegarde et un plan de retour avant de toucher à l’authentification. Si une extension impose son propre hachage, documentez ce cas séparément : un test réussi sur le cœur seul ne valide pas cette extension. Pour choisir une architecture applicative plus large, consultez notre comparatif WordPress, Django et Rails.
Une dernière question ?
Faut-il réinitialiser tous les mots de passe après WordPress 6.8 ?
Pas pour ce seul changement : WordPress maintient la compatibilité avec les anciens hashes. Une réinitialisation peut être nécessaire pour une autre raison, notamment une compromission.
Peut-on récupérer le mot de passe à partir du hash ?
Le hachage n’est pas conçu pour être inversé. Pour un utilisateur qui a oublié son mot de passe, utilisez une procédure de réinitialisation contrôlée.
Bcrypt suffit-il à sécuriser un site WordPress ?
Non. Les mises à jour, les droits d’accès, les sauvegardes, la sécurité des sessions et la protection contre les tentatives abusives restent nécessaires.