Stockage Des Mots De Passe : Quoi Utiliser en 2026

Le stockage des mots de passe est l’un des rares domaines du logiciel où il existe une vraie bonne réponse, publiée, tenue à jour et gratuite. C’est aussi l’un de ceux que l’on rate le plus régulièrement, parce que les mauvaises réponses ont été justes à une époque et que personne n’y est jamais revenu.

L’échec est rarement exotique. C’est un système bâti en 2016 sur des conseils qui étaient d’actualité en 2012, qui tourne encore, qui accepte encore des connexions, et dont plus personne n’a ouvert la fonction de hachage depuis le départ de la personne qui l’avait écrite.

Si vous ne retenez qu’une chose : utilisez Argon2id, et si vous ne pouvez pas, utilisez bcrypt. Tout le reste de cet article n’est que détail. Une fonction de hachage généraliste comme SHA-256 n’est pas un hachage de mot de passe, quel que soit le nombre de fois où vous l’appliquez, parce que sa rapidité est un objectif de conception, et que la rapidité est précisément ce que vous cherchez à refuser à un attaquant qui détient votre base de données.

Le stockage des mots de passe n’a qu’une seule forme correcte

Stockez une empreinte produite par une fonction délibérément lente et gourmande en mémoire, avec un sel aléatoire unique par mot de passe, en utilisant des paramètres réglés pour votre matériel.

Le guide OWASP sur le stockage des mots de passe énonce les recommandations actuelles avec précision, et il vaut la peine de les citer sous forme de chiffres plutôt que de principes.

Deux remarques sur ce tableau. Le chiffre Argon2id est un minimum, et davantage de mémoire avec moins d’itérations constitue un échange équivalent, si bien qu’une configuration à 47 MiB avec 1 itération offre une sécurité comparable à la référence. Et la limite de 72 octets de bcrypt est une véritable troncature, pas une règle de validation : tout ce qui dépasse 72 octets est ignoré en silence, ce qui compte si vous acceptez de longues phrases secrètes ou si vous pré-hachez l’entrée.

Ces paramètres sont révisés à mesure que le matériel progresse. Lisez la source plutôt que ce tableau au moment de l’implémentation.

Un sel n’est ni facultatif ni suffisant

Un sel est une valeur aléatoire unique stockée à côté de chaque empreinte. Son rôle est étroit et important : il garantit que deux utilisateurs ayant le même mot de passe produisent des empreintes différentes, ce qui met en échec les tables arc-en-ciel précalculées et empêche un attaquant de casser un seul mot de passe pour récupérer tous les comptes qui le partageaient.

Ce qu’un sel ne fait pas, c’est ralentir qui que ce soit. Un attaquant qui possède votre base possède aussi les sels, puisqu’ils doivent être lisibles pour vérifier une connexion. Saler seulement, face à un hachage rapide, revient à laisser l’attaquant s’en prendre à chaque mot de passe individuellement à une vitesse énorme, ce qui est exactement la situation que vous vouliez éviter.

La lenteur doit venir de l’algorithme. C’est tout l’intérêt d’une fonction gourmande en mémoire : elle consomme délibérément des ressources pour qu’un attaquant équipé de matériel spécialisé gagne bien moins d’avantage qu’il n’en tirerait face à un hachage rapide.

Un poivre, valeur secrète appliquée à chaque mot de passe et conservée hors de la base, ajoute une vraie couche, car une simple copie de la base ne suffit plus. Il ajoute aussi une charge opérationnelle, puisque sa rotation impose de rehacher à la connexion suivante et que le perdre bloque tous les comptes. Cela vaut le coup pour les systèmes à forte valeur, et on peut s’en passer dans la plupart des cas.

Les erreurs qui survivent pendant des années

Un hachage rapide avec un sel. SHA-256 avec un sel a l’air responsable et ne l’est pas. La vitesse est la vulnérabilité.

Chiffrer au lieu de hacher. Le chiffrement est réversible par conception, donc une clé existe, et quiconque l’obtient obtient tous les mots de passe en clair. Un mot de passe ne doit jamais être récupérable, seulement vérifiable.

Des facteurs de coût réglés une fois et jamais relevés. Un coût bcrypt choisi en 2015 est nettement plus faible face au matériel de 2026. Relevez-le à la prochaine connexion réussie, quand vous détenez brièvement le mot de passe en clair et pouvez rehacher.

Troncature ou restrictions de caractères. Une longueur maximale inférieure à environ 64 caractères, ou l’interdiction de certains caractères, signale d’ordinaire que le mot de passe est stocké d’une façon qui se soucie de son contenu. Elle ne devrait pas : vous le hachez.

Une comparaison qui fuit par le temps. La vérification doit utiliser une comparaison à temps constant. Les fonctions des bibliothèques standard le font, les tests d’égalité écrits à la main non.

Journaliser le mot de passe. Il atterrit dans un journal d’erreurs, une trace de requête ou un système de supervision, et le voilà à trois endroits dont les contrôles d’accès sont plus faibles que ceux de la base.

Migrer un système existant

Vous ne pouvez pas rehacher ce que vous n’avez pas, puisque vous ne détenez que des empreintes. L’approche praticable consiste à mettre à niveau à la connexion.

Quand un utilisateur s’authentifie avec succès, vous disposez un instant de son mot de passe en clair en mémoire. Vérifiez-le contre l’ancienne empreinte, puis calculez immédiatement la nouvelle avec l’algorithme actuel et remplacez la valeur stockée. En quelques mois, la plupart des comptes actifs migrent sans aucun changement visible pour l’utilisateur.

Suivez l’algorithme enregistrement par enregistrement pour que les deux coexistent, et fixez une date au-delà de laquelle les anciennes empreintes restantes sont invalidées et ces utilisateurs doivent réinitialiser. Les comptes dormants aux empreintes faibles sont exactement ceux que vise un attaquant.

N’enveloppez pas l’ancienne empreinte dans le nouvel algorithme pour aller plus vite. Cela fonctionne, et cela laisse le hachage faible comme véritable frontière de sécurité tout en donnant une apparence moderne.

Ce qui compte plus que l’algorithme

Un hachage correct vous protège quand la base fuit. Il ne fait rien contre l’attaque la plus courante, à savoir quelqu’un qui se connecte avec un vrai mot de passe obtenu ailleurs.

La limitation de débit sur l’authentification, la disponibilité du multifacteur, la vérification des nouveaux mots de passe contre les listes de fuites connues et les alertes sur les schémas de credential stuffing traitent ce point, et tous comptent davantage au quotidien que le choix entre Argon2id et bcrypt. Les contrôles de sécurité des API relèvent de la même famille de problèmes.

Les deux méritent d’être faits, et l’ordre mérite d’être dit franchement : réglez le hachage une bonne fois parce que c’est peu coûteux et durable, puis consacrez l’effort continu au chemin de connexion, là où les attaques arrivent réellement. Mecanik examine les deux dans le cadre de notre analyse de sécurité applicative.

Questions fréquentes

Quel est le meilleur algorithme de hachage de mot de passe en 2026 ? Argon2id, avec au minimum 19 MiB de mémoire, 2 itérations et 1 degré de parallélisme. S’il est indisponible, scrypt avec N=2^17, r=8, p=1 constitue une solution de repli, bcrypt avec un facteur de coût de 10 ou plus convient aux systèmes hérités, et PBKDF2-HMAC-SHA256 à 600 000 itérations couvre les exigences FIPS-140.

Saler les mots de passe suffit-il ? Non. Un sel garantit que des mots de passe identiques produisent des empreintes différentes, met en échec les tables arc-en-ciel et empêche qu’un seul mot de passe cassé n’ouvre tous les comptes qui le partageaient. Il ne ralentit pas l’attaquant, car les sels doivent être lisibles pour vérifier les connexions. La lenteur doit venir d’un algorithme délibérément gourmand en mémoire.

Pourquoi ne pas utiliser SHA-256 pour les mots de passe ? Parce que sa rapidité est un objectif de conception, et que la rapidité est exactement ce que vous cherchez à refuser à un attaquant qui détient votre base. Une fonction de hachage généraliste n’est pas un hachage de mot de passe, quel que soit le nombre de fois où elle est appliquée et qu’elle soit salée ou non.

bcrypt impose-t-il une limite de longueur de mot de passe ? Oui, 72 octets, et tout ce qui dépasse est tronqué en silence plutôt que rejeté. Cela compte si vous acceptez de longues phrases secrètes ou si vous pré-hachez l’entrée avant de la passer à bcrypt, puisque la troncature se produit sans la moindre erreur pour la signaler.

Comment mettre à niveau des empreintes de mot de passe sans les mots de passe des utilisateurs ? À la connexion. Quand un utilisateur s’authentifie, vous détenez un instant son mot de passe en clair : vérifiez-le contre l’ancienne empreinte et rehachez aussitôt avec l’algorithme actuel. Suivez l’algorithme enregistrement par enregistrement pour que les deux coexistent, et fixez une date au-delà de laquelle les anciennes empreintes restantes sont invalidées et ces utilisateurs doivent réinitialiser.