Depuis WordPress 2.5, sorti en 2008, les mots de passe des utilisateurs étaient hachés avec phpass, une bibliothèque robuste pour son époque mais qui n’a pas suivi l’évolution des standards de sécurité cryptographique. WordPress 6.8, sorti en avril 2025, corrige enfin ce point en adoptant bcrypt comme algorithme de hachage par défaut, un changement discret pour l’utilisateur final mais significatif pour la sécurité de fond du logiciel.
Ce n’est pas un changement cosmétique : bcrypt intègre un facteur de coût réglable qui ralentit délibérément chaque calcul de hachage, ce qui rend une attaque par force brute hors ligne, sur une base de données volée, nettement plus coûteuse à mener que face à phpass. Voyons ce que ce changement implique concrètement, pour les sites existants comme pour les développeurs d’extensions qui manipulent des mots de passe.
Pourquoi phpass ne suffisait plus
phpass utilisait un hachage itéré basé sur MD5, avec un nombre d’itérations configurable. Le problème n’était pas tant l’algorithme lui-même à sa création, que son incapacité à suivre l’augmentation continue de la puissance de calcul disponible pour des attaques hors ligne. Un hachage qui demandait un temps de calcul raisonnable en 2008 devient, quinze ans plus tard, cassable à un rythme qui n’a plus rien de dissuasif face au matériel moderne, en particulier les cartes graphiques utilisées pour le calcul massivement parallèle.
bcrypt, construit sur l’algorithme Blowfish, résout ce problème différemment : il intègre un work factor qui peut être augmenté au fil du temps pour compenser les progrès du matériel, sans changer d’algorithme. C’est cette capacité d’ajustement qui en fait un choix plus pérenne que phpass.
Une migration transparente pour les sites existants
Le changement d’algorithme ne provoque aucune interruption pour les utilisateurs existants. WordPress conserve la capacité à vérifier un hachage phpass au moment de la connexion, puis le remplace automatiquement par un hachage bcrypt une fois le mot de passe validé avec succès. Aucune action manuelle n’est nécessaire de la part de l’administrateur du site ni de l’utilisateur.
- Les anciens hachages phpass restent vérifiables normalement à la connexion
- Le hachage est recalculé en bcrypt uniquement après une connexion réussie
- Un compte inactif depuis longtemps conserve son hachage phpass jusqu’à la prochaine connexion
Cette approche progressive évite de forcer une réinitialisation massive des mots de passe sur tous les sites de l’écosystème au moment de la mise à jour vers WordPress 6.8, ce qui aurait été impraticable à l’échelle de millions d’installations.
Ce que ça change pour un compte resté inactif
Un compte qui ne se reconnecte jamais après la mise à jour conserve indéfiniment son hachage phpass d’origine. Sur un site avec des comptes anciens rarement utilisés, mais toujours actifs en base, il peut être pertinent d’envisager une politique de réinitialisation proactive des mots de passe les plus anciens, en particulier sur les comptes disposant de droits élevés.
Ce que ça change pour les développeurs d’extensions
Les fonctions publiques utilisées pour manipuler les mots de passe, wp_hash_password et wp_check_password, conservent la même signature et le même usage. Une extension qui appelait correctement ces fonctions plutôt que de réimplémenter sa propre logique de hachage n’a rien à modifier pour bénéficier automatiquement de bcrypt.
// Toujours la bonne façon de hacher un mot de passe
$hache = wp_hash_password( $mot_de_passe_en_clair );
// Toujours la bonne façon de le vérifier
$valide = wp_check_password( $mot_de_passe_saisi, $hache, $user_id );En revanche, une extension qui aurait, à tort, réimplémenté sa propre logique de hachage basée sur MD5 ou sur une supposition concernant le format interne des hachages phpass, doit être corrigée sans délai : ce type de code contourne justement l’amélioration apportée par WordPress 6.8, et constitue depuis longtemps une mauvaise pratique à proscrire, indépendamment de ce changement.
Un rappel plus large sur la gestion des mots de passe
Ce changement d’algorithme est l’occasion de rappeler quelques principes qui restent valables indépendamment de l’algorithme de hachage utilisé en interne par WordPress.
| Bonne pratique | Pourquoi |
|---|---|
| Ne jamais stocker un mot de passe en clair, même temporairement | Toute fuite de base de données devient immédiatement critique |
| Toujours utiliser wp_hash_password, jamais une implémentation maison | Bénéficie automatiquement des améliorations futures de WordPress |
| Combiner avec l’authentification à deux facteurs sur les comptes sensibles | Le hachage protège la base, pas une session déjà compromise |
Ce genre de changement, invisible pour l’utilisateur final, est exactement le type d’évolution que j’apprécie le plus dans le cœur de WordPress : personne ne le remarque, et pourtant la sécurité de base de millions de sites progresse d’un coup.
En résumé
L’adoption de bcrypt dans WordPress 6.8 referme un écart de sécurité qui datait de 2008, sans imposer la moindre friction aux utilisateurs ni aux développeurs d’extensions respectueux des bonnes pratiques existantes. La migration transparente au fil des connexions illustre une approche prudente et pragmatique, typique du cœur de WordPress : améliorer la sécurité de fond sans casser l’existant, ce qui reste la meilleure garantie qu’un tel changement soit réellement adopté à grande échelle.
