Pourquoi les hash rapides sont dangereux pour les mots de passe
MD5 et SHA-1 tombent en quelques secondes sous un GPU car ils sont rapides et souvent non salés. Découvrez pourquoi les KDF lents comme bcrypt et Argon2 résistent.
Tous les hash ne sont pas des cibles égales. Le facteur le plus déterminant pour savoir si une base de mots de passe volée sera cassée en une après-midi ou restera sûre pendant des années, c'est la vitesse de l'algorithme de hachage. Cela semble paradoxal — rapide ne devrait-il pas être un atout ? — mais pour le stockage des mots de passe, la rapidité est précisément le problème.
La vitesse est l'alliée de l'attaquant
Un hash cryptographique comme MD5 ou SHA-1 a été conçu pour être rapide : pour vérifier un fichier ou signer un message, on veut une empreinte calculée instantanément. Cette même rapidité est un cadeau pour l'attaquant. Un GPU moderne calcule des milliards de hash MD5 par seconde. Quand l'algorithme est rapide, le goulot d'étranglement disparaît, et l'attaquant n'est limité que par le nombre d'essais qu'il peut générer.
Aggravez la situation en laissant le hash non salé, et deux choses se produisent. D'abord, des mots de passe identiques produisent des empreintes identiques : casser un compte casse tous les comptes qui réutilisaient le mot de passe. Ensuite, l'attaquant peut recourir à des rainbow tables précalculées — d'immenses fichiers de correspondance qui échangent du stockage contre l'inversion instantanée des empreintes courantes. Un MD5 non salé d'un mot de passe faible est, en pratique, déjà cassé avant même le début de l'attaque.
hashcat -m 0 -a 0 dump.txt rockyou.txt
Pointez cela vers une liste de hash MD5 non salés et les mots de passe courants tombent en quelques secondes.
Les sels aident, mais ne suffisent pas
Ajouter un sel — une valeur aléatoire unique mêlée à chaque mot de passe avant le hachage — règle le problème des rainbow tables. Chaque empreinte devient unique, le précalcul devient inutile, et l'attaquant doit attaquer chaque hash individuellement. C'est une véritable amélioration. Mais un sel ne ralentit pas un essai isolé. Face à un MD5 salé mais rapide, le GPU enchaîne encore des milliards de tentatives par seconde ; l'attaquant a simplement perdu le raccourci, pas la vitesse.
Les KDF lents et gourmands en mémoire résistent par conception
La vraie défense consiste à rendre chaque essai coûteux à dessein. Les fonctions de hachage de mots de passe comme bcrypt, sha512crypt, md5crypt et le moderne Argon2 sont des fonctions de dérivation de clé bâties autour d'un facteur de coût réglable. Au lieu d'une seule opération rapide, elles effectuent des milliers d'itérations, et Argon2 exige en plus de grandes quantités de mémoire, ce qui neutralise le parallélisme d'un GPU.
Un hash bcrypt au coût 12 peut mettre un quart de seconde à se calculer. C'est imperceptible pour un utilisateur qui se connecte, mais cela fait s'effondrer le débit de l'attaquant, de milliards par seconde à quelques milliers. Le dictionnaire qui vide une base MD5 en quelques secondes mettrait des siècles contre un bcrypt bien réglé.
À retenir pour les défenseurs
Si vous stockez des mots de passe, les règles tiennent en peu de mots. N'utilisez jamais de MD5 ou SHA-1 brut pour des identifiants. Salez toujours — mais considérez le sel comme un minimum, pas comme une solution. Choisissez un KDF lent et gourmand en mémoire (Argon2id quand c'est possible, bcrypt ou sha512crypt sinon) et augmentez le facteur de coût à mesure que le matériel s'accélère. Quand vous devez confirmer quel algorithme utilise réellement un hash fuité, l'index des types de hash et le guide précédent sur l'identification d'un hash inconnu vous le diront en quelques secondes — en privé, dans votre navigateur.