# L’algorithme de hachage phpass a longtemps toléré des mots de passe faibles, avant bcrypt > Pendant près de vingt ans, WordPress a haché les mots de passe avec phpass. Retour sur les limites de cet algorithme, désormais remplacé par bcrypt depuis la 6.8. - Auteur : WordPress Développement - Publié le : 2025-05-20 - Mis à jour le : 2025-05-20 - Catégorie : Sécurité - URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/phpass-mots-de-passe-faibles-avant-bcrypt/ ## L’essentiel - phpass date de 2005 et visait la compatibilité large, pas la robustesse maximale - Son coût de calcul fixe est devenu insuffisant face au matériel moderne - bcrypt, natif depuis WordPress 6.8, corrige ce point sans migration nécessaire 2005 : c'est l'année où le framework *phpass* (« Portable PHP password hashing framework ») est intégré à WordPress, à une époque où PHP ne proposait encore aucune fonction native dédiée au hachage de mots de passe — `password_hash()` n'arrivera qu'avec PHP 5.5, soit huit ans plus tard. Le cœur de WordPress a conservé ce même mécanisme, avec des ajustements mineurs, jusqu'à son remplacement par bcrypt à l'occasion de la version 6.8, sortie en avril 2025. Comprendre pourquoi phpass a tenu aussi longtemps, et pourquoi son remplacement était devenu nécessaire, éclaire une partie de l'histoire de la sécurité de WordPress souvent réduite à une simple ligne de changelog. ## Pourquoi phpass a été choisi en 2005 À sa création, phpass visait un objectif précis : fonctionner sur le plus grand nombre possible de configurations d'hébergement mutualisé, y compris des environnements PHP anciens sans extension `bcrypt` ni `mcrypt` disponible. L'algorithme reposait sur des passages répétés de la fonction `md5()`, avec un nombre d'itérations codé sous forme d'un caractère dans le hachage stocké, permettant d'ajuster le coût de calcul sans changer de format de stockage. Ce choix était pragmatique pour l'époque : la priorité donnée à la compatibilité universelle, plutôt qu'à l'algorithme théoriquement le plus robuste, a permis à WordPress de fonctionner sur une variété d'hébergements que peu de concurrents pouvaient égaler à ce moment-là. ## Ce qui a fini par poser problème Le nombre d'itérations par défaut de phpass, fixé une fois pour toutes dans le cœur, n'a pratiquement pas évolué depuis son introduction, alors que la puissance de calcul disponible pour tenter de casser un hachage par force brute a considérablement augmenté sur la même période. Un coût de calcul jugé raisonnable en 2005 devient, mécaniquement, beaucoup plus rapide à casser vingt ans plus tard sur du matériel moderne, en particulier avec des cartes graphiques optimisées pour le calcul parallèle. > L'essentiel à retenir : phpass date de 2005 et visait la compatibilité large, pas la robustesse maximale ; Son coût de calcul fixe est devenu insuffisant face au matériel moderne ; bcrypt, natif depuis WordPress 6.8, corrige ce point sans migration nécessaire `md5()`, la fonction de base utilisée par phpass, n'a par ailleurs jamais été conçue pour le hachage de mots de passe : c'est une fonction de hachage générique, rapide par construction, ce qui constitue précisément l'inverse de la propriété recherchée pour ralentir une attaque par force brute. ## bcrypt : un algorithme pensé pour être lent bcrypt, publié dès 1999 mais resté longtemps hors du cœur de WordPress faute de disponibilité universelle dans PHP, repose sur un principe différent : un facteur de coût explicite et ajustable, conçu pour rester délibérément lent à calculer, ce qui ralentit proportionnellement toute tentative de force brute. La fonction native `password_hash()` de PHP, disponible depuis PHP 5.5, expose cet algorithme de façon standardisée, sans dépendance externe. Le passage à bcrypt dans WordPress 6.8 s'est fait sans migration explicite demandée aux administrateurs : les mots de passe existants, encore hachés en phpass, sont transparently re-hachés en bcrypt à la prochaine connexion réussie de chaque utilisateur, un mécanisme de transition qui évite une rupture brutale tout en accélérant l'adoption du nouvel algorithme au fil du temps. ### Ce que cela change concrètement pour un développeur - Aucune action requise sur un site à jour : la transition est gérée par le cœur - Un mot de passe jamais utilisé depuis la mise à jour reste haché en phpass jusqu'à la prochaine connexion - Les fonctions publiques comme `wp_check_password()` continuent de fonctionner de façon identique du point de vue de l'appelant ## Une transition plus discrète qu'il n'y paraît Ce type de changement, profond dans son fonctionnement interne mais quasiment invisible pour l'utilisateur final, illustre une constante de l'évolution du cœur de WordPress : privilégier une migration progressive et rétrocompatible plutôt qu'une rupture qui obligerait chaque site à une intervention manuelle. La documentation du changement reste consultable sur developer.wordpress.org et sur les notes de version officielles de WordPress 6.8. > Un algorithme de hachage n'est jamais définitivement sûr ; il est sûr pour une puissance de calcul donnée, à un moment donné. ## Ce qu'il faut retenir phpass n'était pas un choix négligent en 2005 : c'était un compromis raisonnable pour l'écosystème d'hébergement de l'époque. Son remplacement par bcrypt, natif depuis WordPress 6.8, ne corrige pas une erreur de conception mais adapte le cœur à une réalité matérielle qui a radicalement changé en deux décennies. Retenir cette histoire aide à comprendre pourquoi aucun algorithme de hachage ne doit être considéré comme définitivement acquis, y compris bcrypt lui-même sur le long terme.