PBKDF2 Générateur de Hachage

A: Cet outil génère une chaîne hash autonome : {itérations}:{algorithme}:{sel_base64}:{clé_dérivée_hex}.
Par exemple : 600000:sha256:abc123...==:d4e5f6....
Composants :
itérations : Nombre de rounds HMAC utilisés (ex. : 600000).
algorithme : Fonction de hachage (sha256 ou sha512).
sel_base64 : Sel aléatoire encodé en Base64.
clé_dérivée_hex : Clé dérivée encodée en hexadécimal.
Pour vérifier, entrez en mode Déchiffrer : motdepasse|{chaîne hash complète}.

A: PBKDF2 n'est pas résistant à la mémoire — il peut être parallélisé sur GPU à faible coût. Un GPU moderne peut calculer environ 1 à 2 milliards d'itérations PBKDF2-SHA256 par seconde. Avec 600 000 itérations par hash, cela représente encore ~1 600 tentatives de hash par seconde par GPU. Le nombre élevé d'itérations est le mécanisme de défense principal — il multiplie directement le coût pour l'attaquant. OWASP 2023 fixe 600 000 comme minimum pour SHA-256 ; utilisez 210 000 pour SHA-512. Augmentez ces valeurs avec le temps.

A: PBKDF2 : Résistant au calcul uniquement, pas à la mémoire. Parallélisable sur GPU. Approuvé FIPS 140-2. Nécessite des itérations très élevées. Idéal pour les environnements réglementés FIPS. bcrypt: Résistant au calcul, ~4Ko de mémoire, résistance GPU modérée. Limite de 72 octets pour les mots de passe. Ne peut pas dériver des clés de longueur arbitraire. Argon2id: Résistant à la mémoire, résistant GPU/ASIC, préférence OWASP moderne. Non approuvé FIPS. Performance à sécurité équivalente : Argon2 est nettement plus rapide que PBKDF2 au même niveau de sécurité effectif grâce à la résistance mémoire.

A: Oui. PBKDF2 est explicitement défini dans NIST SP 800-132 et approuvé sous FIPS 140-2. Cela en fait le choix obligatoire pour les agences fédérales américaines, les contractants, les systèmes de santé soumis à HIPAA et les applications financières nécessitant la conformité PCI-DSS. Argon2 et scrypt ne sont pas approuvés FIPS. Si la conformité FIPS est requise, PBKDF2 est actuellement la seule option largement disponible. Vérifiez que votre implémentation PBKDF2 utilise un module cryptographique validé FIPS.

A: Le sel est une valeur aléatoire ajoutée au mot de passe avant le hachage pour s'assurer que deux mots de passe identiques produisent des clés dérivées différentes. Sans sel, les attaquants peuvent utiliser des tables arc-en-ciel précalculées pour craquer plusieurs hashes simultanément. Le sel n'a pas besoin d'être secret — il doit juste être unique par mot de passe. Le sel est inclus dans la chaîne de sortie et doit être stocké avec la clé dérivée pour reproduire le même hash lors de la vérification. Ne jamais réutiliser des sels entre les mots de passe.

A: Définissez la longueur de clé à 32 octets (256 bits) pour dériver directement une clé AES-256. Utilisez 600 000 itérations avec SHA-256. Stockez le sel avec vos données chiffrées. Lors du déchiffrement, redérivez la clé avec le même mot de passe, sel, itérations et algorithme, puis utilisez-la pour déchiffrer avec AES-256-GCM. C'est exactement ainsi que fonctionnent le chiffrement de disque LUKS, la protection des données iOS et de nombreux gestionnaires de mots de passe. La clé dérivée est déterministe — les mêmes entrées produisent toujours la même clé.