Symptôme (ou plutôt, question posée par le client). Après la mise à jour d’un site vers WordPress 6.8, sorti en avril 2025, le responsable technique d’un client a posé une question légitime : « Si WordPress utilise maintenant bcrypt à la place de l’ancien système, est-ce que tous mes utilisateurs vont être déconnectés, ou pire, est-ce que leurs mots de passe existants vont cesser de fonctionner ? » C’est une inquiétude compréhensible face à un changement d’algorithme de hachage qui touche à l’authentification de plusieurs milliers de comptes actifs sur ce site, un réseau de forums communautaires cumulant une décennie d’historique de comptes créés sous d’anciennes versions de WordPress.
Diagnostic : comprendre ce que WordPress 6.8 change réellement
Depuis ses origines, WordPress utilisait phpass, une bibliothèque de hachage de mots de passe conçue au milieu des années 2000, reposant sur des itérations de MD5. Ce choix, raisonnable à l’époque, était devenu daté face aux algorithmes modernes conçus spécifiquement pour résister aux attaques par force brute sur du matériel actuel, en particulier bcrypt, qui intègre un facteur de coût ajustable rendant chaque tentative de calcul volontairement coûteuse en temps processeur. WordPress 6.8 a remplacé phpass par une implémentation basée sur la fonction native PHP password_hash(), utilisant l’algorithme bcrypt par défaut.
Le point essentiel à comprendre, qui répond directement à l’inquiétude du client, est que WordPress ne procède à aucune purge ni migration en masse au moment de la mise à jour elle-même. Le hash d’un mot de passe existant, stocké en base sous l’ancien format phpass, reste parfaitement valide et continue de fonctionner sans aucune interruption pour l’utilisateur concerné.
Comment la migration se produit réellement
La migration vers bcrypt se fait de façon opportuniste, à la connexion, et uniquement à ce moment précis. Lorsqu’un utilisateur saisit son mot de passe pour se connecter, WordPress vérifie d’abord si le hash stocké correspond à l’ancien format phpass. Si c’est le cas, et que le mot de passe saisi est validé avec succès contre ce hash, WordPress recalcule immédiatement un nouveau hash bcrypt à partir de ce même mot de passe en clair (disponible en mémoire à cet instant précis de la connexion, jamais stocké tel quel), et remplace l’ancien hash phpass par le nouveau en base de données :
// Simplification du mécanisme interne de wp_check_password()
function wp_check_password( $password, $hash, $user_id = '' ) {
if ( wp_is_phpass_hash( $hash ) ) {
$valide = phpass_check( $password, $hash );
if ( $valide && $user_id ) {
// Migration transparente vers bcrypt à la volée
wp_set_password( $password, $user_id );
}
return $valide;
}
// Sinon, vérification directe via password_verify() (bcrypt)
return password_verify( $password, $hash );
}Concrètement, un compte qui ne se reconnecte jamais après la mise à jour vers WordPress 6.8 conserve indéfiniment son hash phpass, ce qui reste un fonctionnement parfaitement normal et documenté : la migration n’est jamais forcée, elle attend l’occasion naturelle de la prochaine authentification réussie.
Ce qu’il faut vérifier après la mise à jour
Sur le site du client, plusieurs vérifications ont permis de confirmer que la migration progressive se déroulait sans incident :
- Une requête SQL de suivi, exécutée périodiquement, pour mesurer la progression de la migration sans jamais exposer les hashs eux-mêmes dans un journal :
SELECT
SUM(CASE WHEN user_pass LIKE '$P$%' THEN 1 ELSE 0 END) AS phpass_restants,
SUM(CASE WHEN user_pass LIKE '$2y$%' THEN 1 ELSE 0 END) AS bcrypt_migres
FROM wp_users;Sur ce site, la requête a montré une migration progressive : environ quinze pour cent des comptes s’étaient reconnectés et migrés vers bcrypt dans la semaine suivant la mise à jour, un rythme cohérent avec la fréquence de connexion habituelle des utilisateurs de ce forum.
Le point d’attention réel : les intégrations tierces qui lisent le hash directement
La véritable précaution à prendre ne concerne pas les utilisateurs finaux, dont l’expérience reste inchangée, mais les intégrations tierces qui auraient, par le passé, implémenté une logique dépendant explicitement du format phpass. Sur ce site, une extension de synchronisation avec un forum externe (phpBB) comparait directement les hashs de mots de passe entre les deux systèmes pour permettre une connexion unique, une pratique déjà fragile en soi, mais qui reposait implicitement sur le format phpass, compatible par coïncidence avec un ancien format utilisé par phpBB.
Cette extension a dû être révisée pour ne plus comparer les hashs directement, mais s’appuyer sur l’API d’authentification standard de WordPress via le filtre authenticate, indépendante du format de hachage sous-jacent :
add_filter( 'authenticate', function( $user, $username, $password ) {
if ( is_wp_error( $user ) ) {
return $user;
}
// Synchronisation vers phpBB déclenchée après authentification WordPress réussie,
// jamais par comparaison directe de hash.
monsite_synchroniser_phpbb( $username, $password );
return $user;
}, 30, 3 );Précautions à prendre avant une mise à jour vers 6.8 sur un parc existant
Pour un site gérant un volume important de comptes anciens, plusieurs précautions restent recommandées avant la mise à jour :
- Recenser toute extension ou intégration qui accède directement au champ
user_passen base plutôt que de passer par les fonctions d’authentification standards de WordPress. - Ne jamais forcer une réinitialisation de mot de passe en masse « par précaution » : elle est inutile, la migration se fait déjà automatiquement et sans risque à la prochaine connexion réussie.
- Vérifier que la version de PHP du serveur (8.0 minimum recommandé pour cette version de WordPress) prend bien en charge
password_hash()avec l’algorithme bcrypt, disponible nativement depuis PHP 5.5.
La meilleure migration de sécurité est souvent celle qu’on ne remarque pas : ici, personne n’a eu besoin de changer son mot de passe pour bénéficier d’un hachage plus robuste.
Ce qu’il faut retenir
L’arrivée de bcrypt dans WordPress 6.8 ne provoque aucune rupture pour les utilisateurs existants : la migration se produit silencieusement, mot de passe par mot de passe, à chaque connexion réussie, sans jamais nécessiter d’intervention manuelle ni de purge de session. Le seul point de vigilance réel concerne les intégrations tierces qui auraient, par le passé, pris une dépendance implicite sur le format phpass plutôt que de passer par les mécanismes d’authentification officiels de WordPress, une pratique à corriger indépendamment de cette migration, puisqu’elle constitue en elle-même une fragilité d’architecture.
