Comment stocker les mots de passe, et pourquoi utiliser bcrypt/scrypt/argon2 plutôt que des hachages rapides ?
Réponse courte
Stockez les mots de passe avec une fonction de hachage de mots de passe délibérément lente, salée et adaptative — bcrypt, scrypt ou Argon2 — jamais un hachage générique rapide comme SHA-256 ou MD5. Les hachages rapides sont conçus pour la vitesse, donc des attaquants avec des GPU peuvent tester des milliards d'essais par seconde contre une base de données fuitée. Les hachages lents ont un facteur de travail ajustable (et un coût mémoire) qui rend chaque essai coûteux, gardant le brute force impraticable même après une fuite.
C'est une question décisive en appsec. La mauvaise réponse (« on fait un SHA-256 du mot de passe ») semble responsable mais c'est exactement l'erreur qui transforme une fuite de base de données en prise de contrôle massive de comptes. L'idée clé est que le hachage de mots de passe doit être lent.
Pourquoi les hachages rapides échouent
SHA-256, SHA-1 et MD5 sont conçus pour être rapides — une vertu pour l'intégrité de fichiers, où l'on hache des gigaoctets rapidement. Mais la vitesse est un handicap pour les mots de passe. Quand un attaquant vole une table de mots de passe hachés, il la casse hors ligne, et avec des GPU modernes il peut calculer des milliards d'essais de hachage rapide par seconde. Combiné à des listes de mots fuitées et au fait que les utilisateurs choisissent des mots de passe prévisibles, la plupart des mots de passe hachés rapidement tombent en quelques heures. Le salage aide contre le précalcul mais ne change rien à la vitesse brute de devinette.
Pourquoi les hachages lents et adaptatifs l'emportent
Les hachages de mots de passe dédiés coûtent délibérément cher par évaluation :
- bcrypt a un facteur de travail (coût) ajustable que l'on augmente au fil du temps à mesure que le matériel s'améliore ; il est éprouvé depuis des décennies.
- scrypt ajoute la dureté mémoire, forçant chaque essai à consommer beaucoup de RAM, ce qui freine le cassage parallèle bon marché sur GPU/ASIC.
- Argon2 (vainqueur de la Password Hashing Competition) ajuste temps, mémoire et parallélisme indépendamment et est la recommandation par défaut moderne.
L'idée commune : faire en sorte qu'un seul essai prenne, disons, 100 ms au lieu d'une nanoseconde. C'est invisible pour une connexion légitime mais multiplie le coût d'un attaquant par des ordres de grandeur, de sorte que même une base de données fuitée résiste au cassage. Les sels (uniques par utilisateur) restent obligatoires par-dessus, pour stopper les tables arc-en-ciel et les fuites de hachages identiques.
Pourquoi ne pas chiffrer à la place ?
Le chiffrement est réversible, ce qui signifie que la clé existe quelque part — et si la clé est compromise, chaque mot de passe est récupéré instantanément. Le hachage est unidirectionnel par conception ; vous vérifiez en re-hachant l'entrée, jamais en déchiffrant. Vous ne devriez jamais avoir besoin du texte en clair.
Ce que recherchent les recruteurs
Nommer bcrypt/scrypt/Argon2, expliquer la logique lent-par-conception / facteur de travail, le salage par-dessus, la dureté mémoire en bonus, et un ferme « hacher, ne pas chiffrer » avec le raisonnement.
Questions de suivi probables
- Pourquoi la rapidité est-elle une faiblesse pour un hachage de mot de passe mais une force pour une somme de contrôle de fichier ?
- Que défend la dureté mémoire d'Argon2 que bcrypt ne défend pas ?
- Pourquoi ne faut-il jamais chiffrer (de façon réversible) les mots de passe stockés ?