Générateur et vérificateur de hachage de mot de passe

SHA-256 sur un GPU moderne effectue des milliards de devinettes par seconde. Un mot de passe de 8 caractères compte nettement moins de 10¹³ combinaisons — des heures de GPU, quelques minutes sur une grosse machine. Les fonctions de hachage de mots de passe (KDF) luttent contre cela avec des paramètres de coût : bcrypt répète son cœur 2^coût fois, PBKDF2 itère HMAC des centaines de milliers de fois, et scrypt et Argon2id exigent en plus des mégaoctets de mémoire par tentative, si bien que les GPU (rapides mais pauvres en mémoire par cœur) perdent leur avantage. Un sel — aléatoire, stocké en clair dans la chaîne de hachage — empêche les tables arc-en-ciel précalculées et oblige chaque tentative à être calculée à neuf pour chaque utilisateur.

Un GPU compte des milliers de cœurs, mais chaque cœur n’a accès qu’à une petite quantité de mémoire rapide. Une KDF qui exige 19 MiB de jeu de travail par tentative limite un attaquant au nombre de tentatives parallèles qu’il peut loger dans des blocs de 19 MiB de mémoire — c’est pourquoi Argon2id à 19 MiB peut être, en pratique, plus robuste que bcrypt au coût 15, bien qu’il prenne moins de temps réel sur votre portable. PBKDF2 n’a pas de réponse à cela : son seul réglage est le nombre d’itérations, que le silicium met à l’échelle linéairement.

Le format modular-crypt / PHC est auto-descriptif : dans $argon2id$v=19$m=19456,t=2,p=1$ICEiIyQlJicoKSorLC0uLw$WTGpK4hf..., les champs sont l’algorithme, la version, les paramètres (m = mémoire en KiB, t = passes, p = voies), le sel en base64 et le hachage en base64. bcrypt est antérieur au standard et utilise sa propre forme compacte : variante $2b$, 12 de coût, puis le sel et le hachage dans l’alphabet base64 propre à bcrypt (./A-Za-z0-9). La vérification de cette page accepte tous ces formats et affiche les champs analysés — collez n’importe quel hachage trouvé et voyez sa décomposition.

• Un hachage rapide pour les mots de passe. Les colonnes de mots de passe en MD5/SHA-1/SHA-256 tombent face aux GPU du commerce à des milliards de devinettes par seconde. Utilisez le générateur de hachage pour les fichiers et les données ; utilisez les algorithmes de cette page pour les mots de passe.
• Partager un sel. Un seul sel pour tous les utilisateurs signifie que des mots de passe identiques produisent des hachages identiques, et les tables arc-en-ciel refont surface. Chaque hachage ici reçoit un sel aléatoire neuf de 16 octets.
• Ignorer les 72 octets de bcrypt. "a"*100 et "a"*72 donnent le même hachage — la fin est tronquée. Cette page avertit dans la zone de saisie lorsque le mot de passe dépasse 72 octets. Argon2 n’a pas une telle limite.
• Comparer des hachages avec == dans votre propre code. La vérification doit être à temps constant ; le moteur de la page le fait en interne (il recalcule puis compare les octets enregistrés), mais si vous reprenez l’approche, utilisez une comparaison à temps constant.
• Régler les paramètres sur une machine de développement rapide. Visez environ 250 à 500 ms de hachage sur le matériel médian de vos utilisateurs de production, et non sur votre poste de travail. Le bouton Test de performance montre ce que ce navigateur subit réellement.
• Recalculer le hachage à chaque vérification de connexion. Vérifiez d’abord ; ne recalculez (par exemple pour augmenter le coût) qu’après une vérification réussie, puis enregistrez la nouvelle chaîne. La fonction PHP password_needs_rehash() existe précisément pour cela.

Lequel choisir ? Argon2id avec au moins les minimums OWASP. Si l’environnement ne le propose pas : scrypt, puis bcrypt (coût tel que le hachage prenne ≥250 ms). PBKDF2 uniquement lorsque la certification l’exige.

Pourquoi un sel aléatoire apparaît-il dans la chaîne de sortie ? Le sel n’est pas un secret — il est volontairement stocké en clair dans la chaîne PHC, si bien que la vérification n’a besoin que de la chaîne et du mot de passe candidat. Son rôle est l’unicité, non le secret.

La variante a-t-elle de l’importance ($2a$ / $2b$ / $2y$) ? Pour des mots de passe ASCII, elles produisent des hachages identiques ; $2a$ est l’original des années 1990, $2b$ a corrigé un rare bogue d’extension de signe (2014), $2y$ est le marqueur de PHP indiquant que la correction est présente. La vérification accepte les trois.

Combien de temps un hachage doit-il prendre ? Environ 250 à 500 ms par connexion sur du matériel serveur. Sous 100 ms, le craquage hors ligne devient bon marché ; au-delà de 1 s, les utilisateurs se plaignent avant que la sécurité ne s’améliore.

Puis-je vérifier un hachage produit ailleurs ? Oui — collez-le et indiquez le mot de passe candidat. Formats éprouvés : password_hash de PHP (bcrypt $2y$ et Argon2id), passlib de Python, le hacheur argon2 de Django, et le format de chaîne scrypt de l’outil scrypt de Tarsnap.

Que fait le bouton « Test de performance » ? Il hache une fois le mot de passe courant avec chaque algorithme aux paramètres par défaut de la page, et indique le temps réel dans ce navigateur — une idée des écarts de coût, non une mesure rigoureuse.