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
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.
