WordPress 6.8 : ce que le passage a bcrypt change vraiment pour la securite

Pourquoi ce changement compte encore en 2026

WordPress 6.8 a ete publie en avril 2025. Avant la sortie, l'equipe Core a annonce un changement important : les mots de passe utilisateurs ne reposent plus sur l'ancien mecanisme portable phpass, mais sur bcrypt via les fonctions natives de PHP.

Un an plus tard, ce changement reste important pour deux raisons. D'abord, beaucoup de sites tournent encore sur la branche 6.8.x. Ensuite, une partie de l'ecosysteme WordPress avait pris l'habitude d'inspecter directement les anciens formats de hash ou de brancher du code custom autour de l'authentification.

Ce qui change exactement

Le coeur de WordPress a mis a jour wp_hash_password() et wp_check_password() pour utiliser password_hash() et password_verify() avec bcrypt, en ajoutant un pre-hachage SHA-384 afin d'eviter la limite de 72 octets de bcrypt.

Concretement, le nouveau prefixe par defaut pour les mots de passe utilisateurs devient `$wp$2y$`.

En parallele, WordPress a introduit wp_fast_hash() et wp_verify_fast_hash() pour plusieurs secrets applicatifs generes aleatoirement. D'apres la note officielle du Core, les application passwords, les cles de reinitialisation de mot de passe, les cles de demande de donnees personnelles et la recovery mode key passent vers BLAKE2b via Sodium.

Ce qui ne change pas

Le point rassurant est explicite dans la documentation officielle : les anciens hashes phpass restent supportes. Il n'y a donc pas de reset general des mots de passe a organiser.

Autrement dit :

Autre detail important : la note officielle precise que les post passwords continuent d'utiliser phpass pour le moment. Le changement ne couvre donc pas tout le systeme de bout en bout.

Ce que les developpeurs doivent verifier

La page officielle est claire sur un point : le code qui appelle simplement `wp_hash_password()` et `wp_check_password()` n'a pas besoin d'etre modifie.

En revanche, il faut verifier les cas suivants.

1. Le code qui inspecte directement les prefixes de hash

Si un plugin, un mu-plugin ou un snippet suppose que tous les hashes WordPress commencent par `$P$`, il peut se tromper desormais. C'est typiquement le genre de logique fragile qui casse pendant une mise a niveau.

2. Les integrations d'authentification maison

Certaines equipes ont ajoute des passerelles SSO, des scripts de migration, des synchronisations vers un autre systeme ou des controles manuels autour des tables utilisateurs. Si ce code manipule directement les hashes au lieu d'utiliser les fonctions WordPress, il merite une revue.

3. Les plugins qui remplacent la logique native

Le Core a conserve la compatibilite avec le global $wp_hasher et avec des mecanismes alternatifs. C'est utile, mais cela veut aussi dire que les sites ayant empile des surcharges historiques doivent verifier qu'ils n'introduisent pas un comportement incoherent.

4. Les procedures internes de support

Certaines equipes techniques avaient l'habitude de verifier visuellement un hash, de comparer des formats ou de raisonner a partir de l'ancien prefixe. Ces reflexes doivent etre mis a jour.

Ce que ce changement ne corrige pas

C'est le point a ne pas sur-vendre.

Le passage a bcrypt ameliore le stockage des secrets d'authentification. Il ne corrige pas les autres faiblesses courantes d'un site WordPress :

En d'autres termes : mieux hacher un mot de passe est une bonne chose, mais cela ne remplace ni l'hygiene plugin, ni la revue des acces, ni l'audit de la surface d'attaque.

Notre lecture

La mise a jour WordPress 6.8 va dans le bon sens. Le passage a bcrypt et l'introduction de BLAKE2b montrent que le Core continue a moderniser ses primitives de securite.

Mais pour un site en production, la vraie question reste : qu'avez-vous expose autour du CMS ?

Si votre WordPress pilote des comptes clients, des contenus prives, des formulaires sensibles, des exports, des media restreints ou des integrations metier, le risque principal n'est pas seulement le hash du mot de passe. Le risque se situe aussi dans les plugins, les routes REST, les buckets, les webhooks, les roles et les secrets visibles depuis l'exterieur.

C'est exactement ce qu'un revue externe permet de verifier rapidement : non pas si WordPress a fait sa part, mais si votre implementation a fait la sienne.