# PHP 8.4 et bcrypt : ce que WordPress 6.8 change pour un hachage de mot de passe maison

> Explication du passage à bcrypt dans WordPress 6.8 et de son impact sur un code de hachage de mot de passe personnalisé écrit dans un thème.

- Auteur : Clément Hadrot
- Publié le : 2025-10-19
- Mis à jour le : 2025-10-19
- Catégorie : Thèmes
- URL : https://wpmoderne.dev.wordpress-developpement.fr/themes/php84-bcrypt-wordpress-68-hachage-maison/

## L’essentiel

- WordPress 6.8 (avril 2025) remplace phpass par bcrypt pour le hachage des mots de passe
- Un hachage maison basé sur les anciennes fonctions de hooks devient incompatible ou redondant
- La fonction native password_hash() de PHP couvre déjà ce que le code maison tentait de faire

Avril 2025 : WordPress 6.8 remplace l'algorithme historique phpass, utilisé depuis WordPress 2.5, par bcrypt pour le hachage des mots de passe. Ce changement, présenté comme un simple renforcement de sécurité dans les notes de version, a une conséquence directe sur un thème plus ancien qui avait implémenté son propre système de hachage personnalisé via les filtres `check_password` et `wp_hash_password` — un choix qui datait d'une époque où bcrypt n'était pas nativement disponible dans les versions de PHP alors ciblées par WordPress.

Ce billet explique ce que change concrètement WordPress 6.8 pour ce type de code maison, et pourquoi PHP 8.4, sorti en novembre 2023 et désormais largement disponible en hébergement, rend ce hachage personnalisé obsolète. Il ne traite ni la migration des mots de passe déjà stockés en base, ni les extensions tierces d'authentification à deux facteurs.

## Pourquoi un thème avait son propre hachage

Le système historique phpass de WordPress reposait sur des itérations de la fonction `md5()`, une approche jugée suffisante à l'époque de sa conception mais dépassée par les standards de sécurité actuels. Certains projets, notamment ceux visant une conformité renforcée pour des données sensibles, avaient contourné ce système par un filtre personnalisé appliqué au moment de la création et de la vérification du mot de passe.

```
// Code hérité, présent dans functions.php depuis plusieurs années
add_filter( 'check_password', function ( $vérifié, $mot_de_passe, $hash, $user_id ) {
    return password_verify( $mot_de_passe, $hash );
}, 10, 4 );

add_filter( 'wp_hash_password', function ( $hash, $mot_de_passe ) {
    return password_hash( $mot_de_passe, PASSWORD_BCRYPT );
}, 10, 2 );
```

Ce code utilisait déjà `password_hash()` et `password_verify()`, deux fonctions natives de PHP disponibles depuis PHP 5.5. Il anticipait, à sa manière artisanale, exactement ce que WordPress 6.8 a fini par intégrer nativement des années plus tard.

## Ce que change WordPress 6.8

À partir de la version 6.8, WordPress utilise nativement `password_hash()` avec l'algorithme bcrypt pour tout nouveau mot de passe créé ou modifié, sans qu'aucun filtre personnalisé ne soit nécessaire. La fonction `wp_hash_password()` du cœur délègue directement à cette fonction native de PHP, avec une gestion automatique du sel et du facteur de coût.

### Le conflit avec le filtre existant

Le filtre maison présenté plus haut ne casse rien à proprement parler — il continue de s'exécuter et de produire un résultat fonctionnellement identique à ce que fait désormais le cœur nativement. Mais il devient une couche redondante, qui complique la lecture du code pour quiconque reprend le thème sans connaître son historique, et qui peut interagir de façon imprévisible avec de futures évolutions du cœur si celui-ci change sa propre implémentation interne de `wp_hash_password`.

> L'essentiel à retenir : WordPress 6.8 (avril 2025) remplace phpass par bcrypt pour le hachage des mots de passe ; Un hachage maison basé sur les anciennes fonctions de hooks devient incompatible ou redondant ; La fonction native password_hash() de PHP couvre déjà ce que le code maison tentait de faire

## Nettoyer le code maison sans risque

La suppression de ce filtre doit se faire avec prudence, dans cet ordre précis :

1. Confirmer la version de WordPress active sur le site est bien 6.8 ou supérieure avant toute suppression
2. Vérifier qu'aucune autre extension du site ne dépend indirectement de ce filtre personnalisé
3. Retirer le filtre `check_password` et `wp_hash_password` du `functions.php` du thème
4. Tester une connexion complète (déconnexion puis reconnexion) sur un compte existant, pour confirmer que la vérification du mot de passe déjà haché reste valide

Ce dernier point est crucial : bcrypt et l'ancien phpass produisent des formats de hash différents, mais WordPress gère nativement cette transition — un mot de passe existant, haché avec l'ancien système, reste vérifiable, et se voit automatiquement rehaché en bcrypt à la prochaine connexion réussie de l'utilisateur.

### Pourquoi PHP 8.4 renforce encore cette confiance

PHP 8.4, disponible depuis novembre 2023 en version stable et largement déployé chez les hébergeurs mutualisés courants au moment de la sortie de WordPress 6.8, inclut des améliorations de performance sur les fonctions de hachage natives. Utiliser directement les fonctions du langage plutôt qu'une implémentation maison bénéficie automatiquement de ces optimisations, sans aucune modification de code supplémentaire du côté du thème.

> Un code de sécurité maison vieillit rarement bien. Dès qu'une fonctionnalité équivalente devient native dans le langage ou dans le cœur de WordPress, planifiez son retrait — pas par principe, mais parce que le code natif bénéficie d'une maintenance et d'un audit que du code maison isolé n'aura jamais.

## Un point de vigilance sur les tests automatisés

Si le thème dispose de tests automatisés couvrant l'authentification, il est recommandé de les faire tourner explicitement après le retrait du filtre, sur un environnement de préproduction disposant d'une copie récente de la base de production. Un test qui vérifiait auparavant le comportement du filtre personnalisé doit être adapté pour vérifier directement le comportement natif de `wp_hash_password()`, sous peine de masquer une régression silencieuse.

## Notion à retenir

WordPress 6.8 rend obsolète tout hachage de mot de passe maison basé sur les mêmes fonctions PHP natives que le cœur utilise désormais lui-même. Le retrait de ce type de code hérité n'est pas une simple opération de nettoyage cosmétique : c'est une réduction réelle de la surface de maintenance d'un thème, au profit d'une implémentation directement portée et auditée par le cœur de WordPress.