Créer le hash d’un compte administrateur de test
Générez une valeur pbkdf2-sha256$… pour insérer directement un utilisateur dans une base de données de développement ou un fichier de seed, sans écrire de script.
Calculez un hash PBKDF2 avec sel aléatoire, SHA-256 ou SHA-512 et le nombre d’itérations recommandé par l’OWASP, au format pbkdf2-sha256$…, puis vérifiez un mot de passe contre cette valeur. Traitement local.
L’OWASP recommande 600 000 itérations pour SHA-256 et 210 000 pour SHA-512 : plus il y en a, plus chaque essai d’un attaquant coûte cher.
Contient l’algorithme, les itérations, le sel et l’empreinte : c’est tout ce qu’il faut pour vérifier plus tard.
Cet outil dérive un hash PBKDF2 d’un mot de passe avec un sel aléatoire et le nombre d’itérations recommandé, puis vérifie un mot de passe contre une valeur déjà encodée. Il s’adresse aux développeurs qui implémentent ou déboguent un stockage de mots de passe, préparent un compte de test ou veulent comprendre l’effet du sel et des itérations.
PBKDF2, défini par la RFC 8018 (PKCS #5 v2.1), applique une fonction HMAC au mot de passe et au sel, puis réinjecte le résultat dans HMAC des centaines de milliers de fois : chaque tentative d’un attaquant coûte alors autant qu’une connexion légitime. L’outil propose HMAC-SHA-256 avec 600 000 itérations par défaut et HMAC-SHA-512 avec 210 000 itérations, les valeurs minimales de l’OWASP Password Storage Cheat Sheet. Le sel aléatoire (8 à 128 octets, 16 par défaut) rend chaque hash unique même si deux utilisateurs ont le même mot de passe, ce qui neutralise les tables arc-en-ciel. La longueur de clé dérivée va de 16 à 128 octets, 32 par défaut ; à titre de repère, PBKDF2-HMAC-SHA-256 de « password » avec le sel « salt », 1 itération et 32 octets donne 120fb6cffcf8b32c43e7225256c4f837a86548c92ccc35480805987cb70be17b.
Le résultat est encodé sur une ligne : pbkdf2-sha256$600000$<sel>$<hash>, le sel et le hash étant en Base64URL. Cette chaîne contient tout ce qu’il faut pour vérifier plus tard un mot de passe : algorithme, itérations, sel et empreinte attendue. En mode vérification, l’outil lit ces paramètres, recalcule la dérivation avec le mot de passe saisi et compare les deux empreintes en temps constant, pour ne pas révéler par la durée à quel octet elles divergent. Le calcul passe par l’API Web Crypto (deriveBits), si bien que le mot de passe ne quitte jamais votre appareil.
Tapez le mot de passe, choisissez SHA-256 ou SHA-512, puis ajustez si besoin la taille du sel, le nombre d’itérations et la longueur de clé.
L’outil tire un sel aléatoire, calcule PBKDF2 et affiche la valeur encodée pbkdf2-sha256$itérations$sel$hash, prête à être copiée.
Collez une valeur encodée existante et le mot de passe à tester : le résultat indique s’il correspond, avec l’algorithme et les itérations lus dans la valeur.
Générez une valeur pbkdf2-sha256$… pour insérer directement un utilisateur dans une base de données de développement ou un fichier de seed, sans écrire de script.
Collez le hash stocké en base et le mot de passe supposé : l’outil indique s’ils correspondent, ce qui permet de savoir si le problème vient du mot de passe ou du code de vérification.
Comparez le temps de calcul avec 210 000 ou 600 000 itérations sur votre machine pour choisir un réglage qui reste confortable à la connexion tout en ralentissant les attaques hors ligne.
Oui, à condition d’utiliser un nombre d’itérations élevé et un sel unique. Sa limite est de ne pas consommer de mémoire, ce qui le rend plus facile à accélérer sur GPU qu’Argon2id ou scrypt. L’OWASP recommande donc Argon2id en premier choix et PBKDF2 surtout lorsqu’une conformité FIPS-140 est exigée.
Les trois sont des fonctions lentes conçues pour les mots de passe. PBKDF2 ne règle que le temps de calcul ; bcrypt ajoute un peu de mémoire mais tronque les mots de passe à 72 octets ; Argon2id, vainqueur de la Password Hashing Competition, règle à la fois le temps et la mémoire. PBKDF2 a l’avantage d’être disponible partout, y compris dans Web Crypto et les modules validés FIPS.
L’OWASP Password Storage Cheat Sheet recommande au minimum 600 000 itérations pour PBKDF2-HMAC-SHA256 et 210 000 pour PBKDF2-HMAC-SHA512. Le NIST SP 800-63B demande simplement un coût aussi élevé que les performances du serveur le permettent. En pratique, visez un calcul d’environ 100 ms à la connexion sur votre serveur.
Non, le sel est stocké en clair avec le hash, c’est ce que fait la valeur pbkdf2-sha256$… Son rôle est d’être unique et aléatoire pour chaque mot de passe, afin d’empêcher les tables précalculées et de masquer le fait que deux utilisateurs ont le même mot de passe. Un secret supplémentaire conservé hors de la base, appelé poivre, est une protection distincte et optionnelle.
Non, PBKDF2 est à sens unique : on ne peut que deviner des mots de passe et recalculer la dérivation pour chacun. Les itérations rendent chaque essai coûteux, mais un mot de passe courant sera tout de même trouvé rapidement. La robustesse finale dépend donc aussi de la qualité du mot de passe.
Le calcul se fait uniquement dans votre navigateur avec Web Crypto : ni le mot de passe ni le hash ne sont envoyés. Par prudence, préférez néanmoins un mot de passe de test lorsque vous générez des exemples ou partagez une capture d’écran.
Outils associés
Des outils similaires ou complémentaires à celui-ci.
Générez des mots de passe forts et aléatoires de 8 à 128 caractères, avec l’entropie affichée.
Testez la robustesse d’un mot de passe : entropie, motifs faibles, temps de cassage estimé et conseils.
Vérifiez si deux hash ou sommes de contrôle correspondent, quels que soient la casse, les espaces ou les deux-points.
Distinguez chiffrement, hachage, HMAC et dérivation de clé pour choisir le bon mécanisme selon le besoin : confidentialité, intégrité, authentification ou stockage de mots de passe.
Comprenez comment OAuth 2.0, PKCE, JWT, JWK et JWKS s’articulent sans les confondre : autorisation, jetons, clés publiques et vérification.
Apprenez à construire une CSP progressive, comprendre ses directives et éviter les politiques trop permissives ou cassantes.
Comprenez comment SRI utilise une empreinte cryptographique pour vérifier qu’un script ou une feuille de style externe correspond au fichier attendu.