Skip to content

Comment devez-vous stocker les mots de passe des utilisateurs ?

Réponse courte

Ne stockez jamais les mots de passe en clair ni chiffrés de façon réversible, et jamais avec des hachages rapides à usage général comme MD5 ou SHA-256. Utilisez une fonction de hachage de mots de passe lente et exigeante en mémoire — Argon2id (préféré) ou bcrypt — avec un sel aléatoire unique par mot de passe et un facteur de coût ajusté, afin qu'un attaquant qui vole la base de données ne puisse pas casser les hachages de manière réaliste.

Les mots de passe doivent être stockés de telle sorte que même un attaquant qui vole la base de données entière ne puisse pas les récupérer. Cette seule exigence exclut le texte en clair et exclut le chiffrement réversible — si votre serveur peut les déchiffrer, un attaquant qui prend votre clé le peut aussi. La réponse est le hachage de mots de passe à sens unique, mais avec le bon type de hachage.

Pourquoi pas un hachage rapide comme SHA-256 ?

Les hachages à usage général sont conçus pour être rapides, ce qui est exactement faux ici. Les GPU modernes calculent des milliards de hachages SHA-256 par seconde, donc une base volée de hachages SHA-256 de mots de passe peut être cassée à grande échelle, surtout pour les mots de passe courants. Vous voulez une fonction délibérément lente et gourmande en ressources.

Utilisez une fonction de hachage de mots de passe

  • Argon2id — le vainqueur moderne du Password Hashing Competition ; exigeant en mémoire, ce qui résiste au cassage par GPU/ASIC, avec des paramètres ajustables de mémoire, temps et parallélisme. Préféré pour les nouveaux systèmes.
  • bcrypt — éprouvé, avec un facteur de coût configurable que vous augmentez au fil du temps à mesure que le matériel s'améliore. Un choix solide.
  • scrypt / PBKDF2 — acceptables là où les précédents ne sont pas disponibles (PBKDF2 nécessite un nombre d'itérations élevé et est compatible FIPS).

Sels (et poivres)

Un sel est une valeur aléatoire unique stockée à côté de chaque hachage. Il garantit que deux utilisateurs avec le même mot de passe obtiennent des hachages différents, ce qui déjoue les tables arc-en-ciel précalculées et empêche un attaquant de casser de nombreux comptes d'un coup. (bcrypt/Argon2 génèrent et intègrent le sel pour vous.) Un poivre facultatif est un secret ajouté à tous les mots de passe et conservé en dehors de la base de données — par exemple dans un HSM ou la configuration de l'application — afin qu'une fuite limitée à la base ne suffise pas.

Ajustez et migrez

Réglez le facteur de coût pour qu'un seul hachage prenne une fraction notable de seconde sur votre matériel, et augmentez-le au fil du temps. Prévoyez de re-hacher lors de la prochaine connexion lorsque vous mettez à niveau les paramètres.

Les recruteurs recherchent « hachage lent et salé », la mention d'Argon2id ou bcrypt, le rejet du chiffrement et des hachages rapides, et l'explication du pourquoi le sel importe (tables arc-en-ciel / mots de passe identiques).

Questions de suivi probables

  • Pourquoi un sel aléatoire par utilisateur est-il nécessaire même avec un hachage fort ?
  • Qu'est-ce qu'un poivre et où est-il stocké différemment d'un sel ?
  • Pourquoi MD5 et SHA-256 sont-ils de mauvais choix pour le stockage de mots de passe ?

Sources

Recevez 100 questions d'entretien en cybersécurité + réponses

Laissez votre e-mail et nous vous enverrons le pack PDF gratuit et le jeu de flashcards.

Pas de spam. Désabonnez-vous à tout moment.