Avec la sortie de WordPress 6.8 en avril 2025, une avancée majeure en matière de sécurité a été introduite : l’adoption de l’algorithme de hachage bcrypt pour les mots de passe utilisateurs.
Pourquoi passer MD5 à bcrypt ?
Historiquement, WordPress utilisait l’algorithme MD5 ( conçu en 1991) via la bibliothèque phpass pour le hachage des mots de passe.
Bien que cette méthode ait été suffisante jusqu’à présent, elle présente aujourd’hui des vulnérabilités croissantes :
Collisions : Il est possible de générer deux entrées différentes produisant le même hash, compromettant ainsi l’unicité des mots de passe.
En revanche, bcrypt est conçu spécifiquement pour le hachage des mots de passe :
Coût computationnel ajustable : Il permet de définir un facteur de coût, rendant le hachage plus lent et donc plus résistant aux attaques.
Protection contre les attaques par dictionnaire et force brute : Sa lenteur intentionnelle dissuade les tentatives massives de déchiffrement.
Bien que cette méthode ait été suffisante jusqu’à présent, elle présente aujourd’hui des vulnérabilités croissantes :
Collisions : Il est possible de générer deux entrées différentes produisant le même hash, compromettant ainsi l’unicité des mots de passe.
En revanche, bcrypt est conçu spécifiquement pour le hachage des mots de passe :
Coût computationnel ajustable : Il permet de définir un facteur de coût, rendant le hachage plus lent et donc plus résistant aux attaques.
Protection contre les attaques par dictionnaire et force brute : Sa lenteur intentionnelle dissuade les tentatives massives de déchiffrement.
- Vitesse de calcul élevée : MD5 produit une empreinte de 128 bits en un temps très court. Cette efficacité permet à un attaquant de tester un grand nombre de combinaisons de mots de passe en un laps de temps réduit. Par exemple, avec des outils optimisés et du matériel performant, il est possible de tester des millions, de hach MD5 par seconde. Des outils tels que John the Ripper ou Hashcat exploitent cette rapidité pour effectuer des attaques par force brute ou par dictionnaire sur des hachages MD5
- Collisions : Un fichier malveillant peut être conçu pour avoir le même hash qu’un fichier légitime. Cette faille s’appelle la faille par collisions. Depuis 2009, de nombreux chercheurs ont démontré la création d’un certificat d’autorité de certification (CA) frauduleux en exploitant une collision MD5. Alors on utilise plus aujourd’hui : SHA-256, bcrypt ou Argon2 pour garantir l’intégrité des données.
bcrypt est conçu spécifiquement pour les mots de passe
Contrairement à MD5 ou SHA1, bcrypt est un algorithme de hachage spécifiquement conçu pour protéger les mots de passe.
Il présente certains avantages non négligeables :
Il présente certains avantages non négligeables :
– Une lenteur volontaire : il est délibérément lent pour rendre les attaques par brute force inefficaces.
– Un coût ajustable : WordPress peut ajuster le “cost factor” (2^n) selon les ressources serveur disponible.
– Le Salt intégré : chaque hash bcrypt contient un » salt » aléatoire, intégré dans la sortie du hachage.
– Une résistance reconnue aux attaques GPU/FPGA : contrairement à MD5/SHA1, les performances de bcrypt sont bien moins affectées par du matériel spécialisé.
Son fonctionnement dans WordPress 6.8
À partir de la version 6.8, WordPress utilise les fonctions natives de PHP password_hash() et password_verify() avec l’algorithme bcrypt pour le hachage des mots de passe. Cela ne demande pas d’action requise de la part des utilisateurs : Les mots de passe existants restent valides.
Lors de la prochaine connexion ou modification du mot de passe, celui-ci sera automatiquement re-haché avec bcrypt.
Compatibilité assurée : Les fonctions wp_hash_password() et wp_check_password() ont été mises à jour pour utiliser bcrypt, tout en conservant la compatibilité avec les anciens mots de passe hachés avec phpass.
Les détailles sont présenté dans ce tableau ci dessous.
Lors de la prochaine connexion ou modification du mot de passe, celui-ci sera automatiquement re-haché avec bcrypt.
Compatibilité assurée : Les fonctions wp_hash_password() et wp_check_password() ont été mises à jour pour utiliser bcrypt, tout en conservant la compatibilité avec les anciens mots de passe hachés avec phpass.
Les détailles sont présenté dans ce tableau ci dessous.
| Critère | MD5 | bcrypt |
|---|---|---|
| Année de naissance | 1991 | 1999 |
| Conçu pour les mots de passe ? | ❌ | ✅ |
| Taille du hash | 128 bits | 184 bits |
| Sel intégré | ❌ | ✅ |
| Coût ajustable | ❌ | ✅ |
| Résistance aux collisions | ❌ | ✅ |
| Résistance aux attaques GPU/FPGA | ❌ | ✅ |
| Temps de calcul | ⚡ Très rapide | 🐢 Lent volontairement |
| Utilisation dans WordPress | Avant (phpass) | Depuis 6.8 (natif) |
| Fonction native PHP | md5() | password_hash(), password_verify() |
| Recommandé pour mots de passe | ❌ | ✅ |
| Utilisé aujourd’hui ? | ❌ | ✅ |
Le passage à wordpress 6.8
quelles implications pour les développeurs
Cette amélioration rend également inutiles les solutions de sécurité utilisées précédemment, telles que les plugins tiers servant à remplacer phpass par bcrypt. Le cœur de WordPress prend désormais en charge nativement le hachage sécurisé, ce qui simplifie la maintenance et réduit la dépendance à des solutions extérieures. Fini les modifications manuelles viale fichier » pluggable.php ». Enfin, les développeurs ont la possibilité de personnaliser le comportement de hachage via le filtre « wp_hash_password_algorithm », ce qui permet, par exemple, de migrer vers Argon2 si le serveur le prend en charge. Cela ouvre la porte à une adaptabilité renforcée pour les environnements soumis à des exigences de conformité élevées. (RGPD, ISO/IEC 27001, PCI-DSS… ).
Cas pratique :
régénérer un mot de passe via phpMyAdmin
Dans certains cas (perte d’accès admin, réinitialisation d’urgence), il pouvait être nécessaire de recréer manuellement un mot de passe WordPress depuis phpMyAdmin.
Avant WordPress 6.8 (MD5 avec phpass)
Dans phpMyAdmin faillait simplement utiliser une petite procédure facile1 pour changer le mot de passe
Depuis WordPress 6.8 (bcrypt via password_hash)
Avec WordPress 6.8 on passe sur un processus totalement différent, wordpress attend un mot de passe bcrypté, généré via PHP (pas depuis phpMyAdmin directement). Il faudra donc le crypter avant de le déposer dans la BDD.
Avant WordPress 6.8 (MD5 avec phpass)
Dans phpMyAdmin faillait simplement utiliser une petite procédure facile1 pour changer le mot de passe
Depuis WordPress 6.8 (bcrypt via password_hash)
Avec WordPress 6.8 on passe sur un processus totalement différent, wordpress attend un mot de passe bcrypté, généré via PHP (pas depuis phpMyAdmin directement). Il faudra donc le crypter avant de le déposer dans la BDD.
améliorations de sécurité au-delà de bcrypt
Utilisation de BLAKE2b via Sodium
Utilisation de BLAKE2b via Sodium
WordPress 6.8 fait un usage accru de la librairie cryptographique Sodium (intégrée à PHP via libsodium) pour certaines opérations critiques qui étaient jusqu’à présent basées sur des fonctions cryptographiques plus anciennes ou moins sécurisées.
Plus précisément, WordPress utilise désormais BLAKE2b (un algorithme de hachage plus efficace) pour :
Le hachage des clés d’accès pour les mots de passe d’application (Application Passwords), utilisés pour les connexions API REST.
Le hachage des clés de réinitialisation de mot de passe, afin de garantir qu’un lien de réinitialisation ne puisse pas être prédit ou falsifié.
La gestion des demandes d’export ou de suppression de données personnelles dans le cadre du RGPD, en garantissant l’authenticité des actions.
Le mode de récupération de site (site recovery mode), utilisé lors des erreurs critiques, dans le but de sécuriser les jetons d’accès d’urgence.
Cette transition vers BLAKE2b renforce considérablement la sécurité de ces mécanismes, avec un algorithme considéré comme plus rapide que SHA-3 et plus sûr que MD5 ou SHA-1, tout en étant compatible avec des environnements PHP classique.
WordPress 6.8 fait un usage accru de la librairie cryptographique Sodium (intégrée à PHP via libsodium) pour certaines opérations critiques qui étaient jusqu’à présent basées sur des fonctions cryptographiques plus anciennes ou moins sécurisées.
Plus précisément, WordPress utilise désormais BLAKE2b (un algorithme de hachage plus efficace) pour :
Le hachage des clés d’accès pour les mots de passe d’application (Application Passwords), utilisés pour les connexions API REST.
Le hachage des clés de réinitialisation de mot de passe, afin de garantir qu’un lien de réinitialisation ne puisse pas être prédit ou falsifié.
La gestion des demandes d’export ou de suppression de données personnelles dans le cadre du RGPD, en garantissant l’authenticité des actions.
Le mode de récupération de site (site recovery mode), utilisé lors des erreurs critiques, dans le but de sécuriser les jetons d’accès d’urgence.
Cette transition vers BLAKE2b renforce considérablement la sécurité de ces mécanismes, avec un algorithme considéré comme plus rapide que SHA-3 et plus sûr que MD5 ou SHA-1, tout en étant compatible avec des environnements PHP classique.
Renforcement des mécanismes d’authentification
et de session
WordPress 6.8 inclut également des améliorations internes discrètes, mais essentielles concernant la gestion de l’authentification et des sessions utilisateurs :
Meilleure isolation des cookies de session, avec des restrictions renforcées sur les domaines et les sous-domaines, réduisant les risques de session fixation.
Protection accrue contre les attaques CSRF (Cross-Site Request Forgery), notamment dans le traitement des requêtes AJAX et REST.
Optimisation de la durée de vie des jetons de connexion, permettant une meilleure invalidation côté serveur lors de la déconnexion ou de la révocation d’un mot de passe.
Réduction de la surface d’attaque des comptes inactifs, en introduisant une base pour la gestion de l’expiration automatique de certaines sessions ou mots de passe d’application.
Intégration plus stricte de l’authentification dans l’environnement REST API, avec vérifications renforcées des autorisations et du contexte d’appel.
Meilleure isolation des cookies de session, avec des restrictions renforcées sur les domaines et les sous-domaines, réduisant les risques de session fixation.
Protection accrue contre les attaques CSRF (Cross-Site Request Forgery), notamment dans le traitement des requêtes AJAX et REST.
Optimisation de la durée de vie des jetons de connexion, permettant une meilleure invalidation côté serveur lors de la déconnexion ou de la révocation d’un mot de passe.
Réduction de la surface d’attaque des comptes inactifs, en introduisant une base pour la gestion de l’expiration automatique de certaines sessions ou mots de passe d’application.
Intégration plus stricte de l’authentification dans l’environnement REST API, avec vérifications renforcées des autorisations et du contexte d’appel.
Conclusion
La transition de WordPress vers bcrypt dans sa version 6.8 constitue bien plus qu’une simple mise à jour technique. c’est un changement d’approche dans la manière dont WordPress protège ses utilisateurs. Ce choix aligne enfin WordPress sur les meilleures pratiques de sécurité contemporaines, en remplaçant un système de hachage devenu vulnérable par un algorithme résistant, éprouvé et adaptable.
Au-delà de bcrypt, cette version marque également l’arrivée d’une base cryptographique moderne avec BLAKE2b via Sodium, un meilleur cloisonnement des sessions, des mécanismes de protection plus rigoureux contre les attaques CSRF, et une authentification REST API renforcée. Voici autant de mesures invisibles pour l’utilisateur final, mais déterminantes pour un développeur ou un administrateur soucieux de sécurité.
Cette évolution rend désormais inutiles les bricolages historiques, les surcharges dans pluggable.php, et les plugins tiers de hachage. Elle permet par ailleurs aux développeurs exigeants de personnaliser l’algorithme utilisé selon leur propre politique de sécurité, en ouvrant la voie à Argon2 ou d’autres technologies de chiffrement plus avancées.
Pour toutes questions n’hésitez pas contacter moi .
Au-delà de bcrypt, cette version marque également l’arrivée d’une base cryptographique moderne avec BLAKE2b via Sodium, un meilleur cloisonnement des sessions, des mécanismes de protection plus rigoureux contre les attaques CSRF, et une authentification REST API renforcée. Voici autant de mesures invisibles pour l’utilisateur final, mais déterminantes pour un développeur ou un administrateur soucieux de sécurité.
Cette évolution rend désormais inutiles les bricolages historiques, les surcharges dans pluggable.php, et les plugins tiers de hachage. Elle permet par ailleurs aux développeurs exigeants de personnaliser l’algorithme utilisé selon leur propre politique de sécurité, en ouvrant la voie à Argon2 ou d’autres technologies de chiffrement plus avancées.
Pour toutes questions n’hésitez pas contacter moi .
