PBKDF2 en ligne - dérivation de clé

Dérivez une clé cryptographique depuis un mot de passe avec PBKDF2-HMAC directement dans le navigateur. Configurez la fonction de hachage (SHA-1, SHA-256, SHA-384 ou SHA-512), le nombre d'itérations, la longueur de sortie et le salt. Le mode Verify compare un mot de passe candidat avec une valeur PBKDF2 hex existante.

Salt (vide — aléatoire)
Mot de passe
0 caract. · 0 octets
Empreinte à vérifier
Essayer :
Résultat
✓ Traitement local dans le navigateur ✓ La saisie n’est pas envoyée au serveur
Exemples
Mot de passe courant
Fonction de hachage: SHA-256 Itérations: 600000 Longueur de clé (octets): 32
Entrée motdepasse123

Un mot de passe utilisateur typique. Cliquez sur Compute pour dériver une clé avec les paramètres actuels.

Phrase secrète
Fonction de hachage: SHA-256 Itérations: 600000 Longueur de clé (octets): 32
Entrée cheval correct batterie agrafe

Une longue phrase secrète est facile à mémoriser et offre souvent plus d'entropie qu'un mot de passe court.

PBKDF2-HMAC-SHA512
Fonction de hachage: SHA-512 Itérations: 210000 Longueur de clé (octets): 64 Salt (vide — aléatoire): docs-example-salt
Entrée secret-notes-version

Utilise SHA-512, une sortie de 64 octets et un salt d'exemple fixe pour une documentation reproductible ou des tests d'interopérabilité.

Vérification à coût élevé
Fonction de hachage: SHA-256 Itérations: 1000000 Longueur de clé (octets): 32 Salt (vide — aléatoire): login-user-42-unique-salt
Entrée phrase secrete panneau admin

Un calcul PBKDF2-HMAC-SHA256 avec un million d'itérations pour comparer la latence et vérifier que les mêmes paramètres reproduisent la même clé.

Qu'est-ce que PBKDF2 ?

PBKDF2 (Password-Based Key Derivation Function 2) est un algorithme de dérivation de clé à partir d'un mot de passe, défini dans RFC 2898 et standardisé dans NIST SP 800-132. Il prend un mot de passe, un salt, un nombre d'itérations, une fonction pseudo-aléatoire comme HMAC-SHA256 et une longueur de sortie, puis produit une clé cryptographique déterministe.

L'algorithme est volontairement coûteux : chaque itération répète le travail HMAC, ce qui augmente le temps nécessaire pour chaque tentative de mot de passe. Cet outil PBKDF2 en ligne utilise la Web Crypto API du navigateur pour dériver une clé hex localement, sans envoyer le mot de passe ni le salt au serveur.

PBKDF2 est utilisé pour le stockage de mots de passe, les formats de fichiers chiffrés, les sauvegardes de wallets, les jeux de tests API et les systèmes compatibles où un protocole impose PBKDF2-HMAC-SHA256 ou PBKDF2-HMAC-SHA512.

PBKDF2 vs bcrypt vs Argon2

PBKDF2 est l'option de dérivation la plus portable : elle existe dans les navigateurs, OpenSSL, Java, .NET, Python, Node.js, les API des systèmes d'exploitation et de nombreux environnements orientés conformité. Elle convient donc au hachage de mots de passe interopérable, aux migrations legacy et aux systèmes nécessitant PBKDF2_HMAC ou pbkdf2_sha256.

Sa faiblesse est d'être surtout liée au CPU, sans coût mémoire significatif. Des attaquants équipés de GPU ou d'ASIC peuvent paralléliser les essais PBKDF2 beaucoup plus efficacement que des serveurs applicatifs classiques.

bcrypt résiste mieux aux GPU grâce à son petit état mémoire interne. Argon2id est le choix moderne par défaut pour les nouveaux stockages de mots de passe, car il est memory-hard et ajustable. Choisissez Argon2id si vous contrôlez la pile technique ; choisissez PBKDF2 si la compatibilité, Web Crypto, les environnements FIPS ou un protocole existant priment.

Paramètres PBKDF2 : hash, salt, itérations, longueur

Ce générateur PBKDF2 expose les paramètres dont les développeurs ont le plus souvent besoin. Le réglage hash sélectionne le digest HMAC utilisé comme fonction pseudo-aléatoire : SHA-256 est le choix pratique par défaut, SHA-512 est courant dans les déploiements SHA-2, SHA-384 sert à la compatibilité, et SHA-1 ne devrait rester que pour les formats legacy.

Le salt doit être unique pour chaque mot de passe ou clé dérivée. Il n'a pas besoin d'être secret ; stockez-le avec le hash dérivé ou les données chiffrées. En production, générez le salt avec une source aléatoire cryptographiquement sûre. Un salt fixe n'est utile que pour des exemples reproductibles et des vecteurs de test.

Les itérations contrôlent le coût. Des valeurs plus élevées ralentissent à la fois la vérification légitime et l'attaque hors ligne. La valeur par défaut est 600 000 itérations pour PBKDF2-HMAC-SHA256, conformément à la base OWASP 2024. La longueur de clé est la taille de sortie en octets : 32 octets donnent une clé 256 bits et un résultat hex de 64 caractères ; 64 octets donnent une sortie 512 bits.

Générer, vérifier et stocker PBKDF2

Utilisez le mode Hash pour générer une valeur PBKDF2 hex depuis un mot de passe et les paramètres choisis. Utilisez Verify si vous avez déjà une valeur PBKDF2 hex stockée : l'outil dérive à nouveau la clé avec le même salt, hash, nombre d'itérations et longueur, puis indique si les valeurs correspondent.

PBKDF2 ne se déchiffre pas. C'est une fonction de dérivation à sens unique : la vérification consiste uniquement à essayer le mot de passe candidat avec les paramètres d'origine et à comparer la sortie. Si un paramètre change - salt, fonction de hachage, itérations ou longueur - la valeur dérivée change aussi.

Pour de vrais comptes utilisateurs, effectuez le hachage de mots de passe côté serveur avec une bibliothèque maintenue, du rate limiting, de la supervision et un plan de mise à jour des paramètres. Ce calculateur PBKDF2 en ligne sert surtout à apprendre, déboguer l'interopérabilité, documenter des paramètres, créer des vecteurs de test reproductibles et vérifier un hash pendant le développement.

FAQ

OWASP 2024 recommande 600 000 itérations pour PBKDF2-HMAC-SHA-256 et 210 000 pour PBKDF2-HMAC-SHA-512. NIST SP 800-132 recommande au moins 1 000, mais c'est aujourd'hui un plancher très bas. Le bon nombre dépend de votre modèle de menace et de votre matériel : visez environ 100-500 ms sur votre serveur. Plus d'itérations ralentit proportionnellement l'attaquant ; moins d'itérations réduit la latence utilisateur.

Un salt est une valeur aléatoire unique ajoutée à chaque mot de passe avant la dérivation. Sans salt, des mots de passe identiques produisent des hashes identiques, ce qui rend les rainbow tables utiles. Avec un salt unique par utilisateur, l'attaquant doit cibler chaque hash séparément. Le salt n'a pas besoin d'être secret, seulement unique ; 16 octets aléatoires suffisent généralement. Stockez le salt avec le hash.

Choisissez PBKDF2 lorsque vous avez besoin d'un large support de plateformes, d'une validation FIPS ou d'une interopérabilité avec des systèmes legacy. Pour les nouveaux systèmes, Argon2id est généralement meilleur lorsqu'il est disponible. PBKDF2 n'a pas de coût mémoire, donc les attaquants peuvent le paralléliser facilement sur GPU. Pour les applications très sensibles, Argon2id est recommandé.

Non. PBKDF2 est calculé entièrement dans votre navigateur via la Web Crypto API (window.crypto.subtle.deriveBits). Votre mot de passe et le salt ne quittent pas l'appareil : pas de requêtes réseau, pas de logs, pas de traitement serveur.

Non. PBKDF2 n'est pas du chiffrement et n'a pas d'opération de déchiffrement. C'est une fonction de dérivation à sens unique. Pour vérifier un mot de passe, dérivez PBKDF2 à nouveau avec le même salt, la même fonction hash, les mêmes itérations et la même longueur, puis comparez la nouvelle sortie hex à la valeur stockée.

Utilisez PBKDF2-HMAC-SHA256 sauf si votre protocole ou votre base existante impose autre chose. PBKDF2-HMAC-SHA512 est aussi courant, surtout dans les systèmes standardisés sur SHA-512. SHA-384 est disponible pour la compatibilité. Évitez SHA-1 pour les nouveaux designs ; gardez-le seulement pour les formats legacy qui exigent PBKDF2-HMAC-SHA1.

Stockez le hash dérivé, le salt, le nombre d'itérations, la fonction hash et la longueur de clé. La sortie PBKDF2 seule ne suffit pas pour vérifier un mot de passe plus tard, car le vérificateur doit répéter exactement les mêmes paramètres. Certains systèmes encodent tout dans une chaîne ; d'autres utilisent des colonnes séparées.

Non. Le salt doit être unique et de préférence aléatoire, mais ce n'est pas une clé secrète. Son rôle est de faire produire des sorties PBKDF2 différentes à des mots de passe identiques et d'empêcher la réutilisation de tables précalculées. Stockez le salt à côté du hash.

Utilisez-le pour l'apprentissage, la comparaison de paramètres, les tests d'interopérabilité et les vecteurs de test. Pour les comptes de production, calculez et vérifiez PBKDF2 côté serveur avec des salts aléatoires sûrs, du rate limiting, de la supervision et des mises à niveau de paramètres contrôlées. Le hachage côté navigateur seul ne remplace pas les contrôles serveur de stockage des mots de passe.
Outils associés

Générateur HMAC

Générez un HMAC avec un texte et une clé secrète dans votre navigateur.