Vous décidez comment stocker les mots de passe des utilisateurs. Quelle est la bonne approche ?

Le stockage des mots de passe est un problème à la réponse établie, et les examinateurs le posent pour voir si vous optez pour la primitive conçue pour cela ou pour une qui sonne simplement cryptographique. Le bon choix est un hachage de mot de passe lent, salé et à coût mémoire élevé : Argon2 (variante id), bcrypt ou scrypt.

Pourquoi lent-et-salé est le bon outil

Ces fonctions sont conçues pour le stockage d'identifiants. Elles sont délibérément coûteuses à calculer (facteur de coût / coût mémoire ajustable), de sorte qu'un attaquant qui vole la base de hachages ne peut tester ses hypothèses que lentement — transformant un cassage GPU de plusieurs milliards par seconde en une reptation de quelques milliers par seconde. Un sel unique par utilisateur garantit que des mots de passe identiques produisent des hachages différents, ce qui déjoue les rainbow tables précalculées et empêche un attaquant de casser plusieurs comptes d'un coup. La dureté mémoire d'Argon2 émousse encore les attaques par GPU et ASIC.

Pourquoi chaque alternative échoue

• SHA-256 est un hachage rapide et généraliste — exactement la mauvaise propriété ici. Le matériel moderne calcule des milliards de hachages SHA-256 par seconde, donc les hachages volés tombent vite, et ceux sans sel tombent instantanément face aux rainbow tables.
• Chiffrer les mots de passe en AES les rend réversibles : le serveur doit détenir la clé, donc une seule compromission de clé (ou un initié malveillant) expose tous les mots de passe en clair. De plus, vous n'avez jamais besoin de récupérer le mot de passe d'origine — seulement de le vérifier — donc la réversibilité n'a que des inconvénients.
• Le texte clair « mais on verrouille la base » est indéfendable. Une seule fuite de sauvegarde, injection SQL ou réplica mal configuré et tous les identifiants sont perdus. Les ACL de base de données ne remplacent pas le fait de ne pas stocker le secret.

Ce qu'ajoute une bonne réponse

Citez Argon2id (ou bcrypt) avec un coût ajusté et un sel par utilisateur ; mentionnez un pepper optionnel (une clé secrète conservée hors de la base) en défense en profondeur ; et notez que vous re-hacheriez à la connexion pour migrer les données héritées en hachage rapide et relèveriez le facteur de coût au fil du temps, à mesure que le matériel s'améliore.