# wp_hash_password() : la fonction qui a changé de visage avec bcrypt en 6.8

> wp_hash_password() est restée la porte d'entrée unique du hachage des mots de passe WordPress, mais son mécanisme interne a changé en profondeur avec l'arrivée de bcrypt en version 6.8.

- Auteur : WordPress Développement
- Publié le : 2026-10-30
- Mis à jour le : 2026-09-30
- Catégorie : Sécurité
- URL : https://www.wpmoderne.fr/securite/wp-hash-password/

## L’essentiel

- wp_hash_password() reposait depuis toujours sur l'implémentation phpass avant la version 6.8
- Depuis 6.8 elle s'appuie sur password_hash() en bcrypt, une primitive native de PHP
- La fonction reste filtrable, ce qui permet à une extension d'imposer encore un autre algorithme

## Une fonction stable, un contenu qui a basculé

`wp_hash_password( $password )` occupe, dans `wp-includes/pluggable.php`, une place centrale : c'est elle que WordPress appelle chaque fois qu'un mot de passe doit être transformé en une empreinte destinée à être stockée dans la table des utilisateurs, que ce soit à la création d'un compte, à la réinitialisation d'un mot de passe ou à sa modification volontaire par l'utilisateur. Sa signature n'a pas changé depuis des années, ce qui est précisément ce qui a permis de faire évoluer son fonctionnement interne sans casser le code qui l'appelle.

Pendant longtemps, la fonction s'appuyait sur une implémentation embarquée de phpass, une bibliothèque de hachage portable conçue pour fonctionner de façon homogène sur des hébergements très variés, à une époque où PHP ne proposait pas nativement de primitive de hachage de mots de passe robuste. Les empreintes produites étaient reconnaissables à leur préfixe `$P$` ou `$H$`.

## Ce que change la version 6.8

> L'essentiel à retenir : wp_hash_password() reposait depuis toujours sur l'implémentation phpass avant la version 6.8 ; Depuis 6.8 elle s'appuie sur password_hash() en bcrypt, une primitive native de PHP ; La fonction reste filtrable, ce qui permet à une extension d'imposer encore un autre algorithme

Avec la sortie de WordPress 6.8, en avril 2025, `wp_hash_password()` s'appuie désormais sur `password_hash()`, la fonction native de PHP dédiée au hachage sécurisé, configurée pour utiliser l'algorithme bcrypt. Cette primitive existe dans PHP depuis longtemps et bénéficie d'un statut particulier : elle gère elle-même la génération du sel, l'encodage du coût de calcul dans l'empreinte produite, et surtout elle est maintenue par le cœur du langage plutôt que par du code applicatif à faire évoluer manuellement au fil des recommandations de sécurité.

```
// Comportement simplifié depuis WordPress 6.8
function wp_hash_password( $password ) {
    $algorithm = apply_filters( 'wp_hash_password_algorithm', 'bcrypt' );
    // Le mot de passe est d'abord traité puis confié à password_hash() en bcrypt
    return password_hash( $password, PASSWORD_BCRYPT );
}
```

Ce code est une simplification pédagogique de l'idée générale : la fonction réelle contient des étapes supplémentaires de préparation, mais le principe reste que le cœur du calcul repose désormais sur une primitive native plutôt que sur une bibliothèque embarquée dans WordPress lui-même.

## Pourquoi ce choix n'est pas seulement cosmétique

Le passage à bcrypt via `password_hash()` apporte plusieurs bénéfices concrets. D'abord, un facteur de coût réglable, qui détermine combien d'itérations internes l'algorithme effectue avant de produire l'empreinte : plus ce facteur est élevé, plus une tentative de force brute hors ligne devient coûteuse en temps de calcul, sans que l'utilisateur ne perçoive de différence à la connexion. Ensuite, la fonction complémentaire `password_needs_rehash()` permet de détecter automatiquement qu'une empreinte ancienne devrait être recalculée avec des paramètres plus robustes, ouvrant la voie à un renouvellement progressif sans forcer tous les utilisateurs à réinitialiser leur mot de passe le même jour.

Le filtre `wp_hash_password_algorithm`, introduit à cette occasion, garde la porte ouverte : une extension d'entreprise ayant des contraintes particulières, par exemple une intégration avec un annuaire d'authentification externe, peut encore substituer un autre mécanisme sans que le reste de WordPress n'ait besoin de le savoir, tant que la fonction retourne une chaîne cohérente avec ce que `wp_check_password()` saura ensuite interpréter.

> Une fonction qui garde le même nom et la même signature pendant des années peut pourtant changer complètement de moteur sans qu'aucun appelant n'ait à le savoir.

## Cas concret : un formulaire d'inscription personnalisé

Une extension qui gère elle-même la création de comptes, par exemple pour un parcours d'inscription sur mesure, doit continuer à passer par cette fonction plutôt que de réinventer son propre hachage :

```
$user_id = wp_insert_user( array(
    'user_login' => $login,
    'user_pass'  => $mot_de_passe_en_clair, // wp_insert_user appelle wp_hash_password() en interne
    'user_email' => $email,
) );
```

Il ne faut jamais appeler `wp_hash_password()` directement puis stocker le résultat manuellement dans `wp_insert_user()` à la place du mot de passe en clair : la fonction d'insertion applique déjà le hachage elle-même, et hacher deux fois produirait une empreinte du hachage plutôt qu'une empreinte du mot de passe, rendant toute connexion future impossible.

- Toujours confier le mot de passe en clair à wp_insert_user() ou wp_update_user(), jamais une valeur pré-hachée
- Ne jamais appeler wp_hash_password() pour comparer un mot de passe fourni, cette comparaison relève de wp_check_password()
- Garder à l'esprit que le format de l'empreinte produite a changé avec la version 6.8, sans que la signature de la fonction n'en informe le code appelant

## Quand ne pas s'appuyer directement sur cette fonction

Un développeur qui a besoin de vérifier un mot de passe fourni par un utilisateur contre une empreinte existante ne doit jamais reconstruire cette vérification à la main en rappelant `wp_hash_password()` sur la valeur saisie pour comparer les deux chaînes : le sel et le facteur de coût intégrés dans chaque empreinte rendent une telle comparaison directe impossible par construction, bcrypt comme phpass produisant une sortie différente à chaque appel même pour un mot de passe identique. C'est le rôle exclusif de `wp_check_password()`, qui sait interpréter le format de l'empreinte stockée pour choisir la bonne méthode de vérification.