Hash, mots de passe et secrets

Prérequis (cursus dev) : mots de passe et hash.

Pourquoi

« On hash avec SHA-256 » ne suffit pas depuis 15 ans : rainbow tables + GPU testent des milliards de hash/seconde. Stocker un mot de passe, c'est le rendre incraquable même base volée.

Concepts

• Sel + coût : sel unique par mot de passe (anti rainbow tables) + fonction lente et mémoire-dure : bcrypt (coût 10-12), scrypt, argon2id (référence actuelle). SHA/MD5, même salés, sont 1M× trop rapides.
• Jamais en clair, jamais réversible : on ne « déchiffre » pas un mot de passe, on compare des hash. Mot de passe oublié = reset, jamais envoi.
• Politique : longueur > complexité (correct horse battery staple > P@ssw0rd!), pas de rotation forcée absurde (elle produit P@ssw0rd!2), 2FA proposée (TOTP), breach-check (HaveIBeenPwned API : mot de passe déjà fuité ?).

Exemple : le bon pattern (conceptuel)

inscription : hash = argon2id(mdp, sel_aleatoire) → stocker (sel, hash, params)
login : re-hacher avec le sel stocké, comparer en temps constant

Cas réel

Base avec MD5 non salés volée : 80 % craqués en 48 h (rockyou + règles), dont des admins avec réutilisation sur d'autres services (credential stuffing en chaîne). Avec argon2id : même volée, inexploitable en pratique.

Pièges

• « On chiffre les mots de passe (AES) » : réversible = clé volée = tout perdu. Hasher, pas chiffrer.
• Coût trop bas « pour la perf » : le coût se règle (benchmark au deploy), pas se supprime.
• Logs qui capturent le mot de passe (erreur 400 avec le body !) : le hash ne sert à rien si le clair est dans les logs.

À retenir

argon2id/bcrypt + sel unique, jamais réversible, longueur > complexité, breach-check, rien dans les logs.