Hachage des mots de passe : standards 2026

Le stockage des mots de passe est l'un des aspects les plus critiques et les plus mal compris de la sécurité applicative. Une fuite de base de données n'est pas une question de si, mais de quand. La qualité du hachage détermine si cette fuite exposera les mots de passe en clair de vos utilisateurs en quelques heures, ou s'ils resteront inutilisables malgré les moyens considérables d'un attaquant. En 2026, les recommandations du NIST et de l'ANSSI sont claires : les algorithmes lents et à mémoire intensive sont la seule réponse acceptable.

Pourquoi MD5 et SHA-1 sont dangereux

MD5 et SHA-1 ont été conçus pour une toute autre finalité : vérifier l'intégrité de fichiers de manière rapide. Cette rapidité est précisément ce qui les rend catastrophiques pour les mots de passe. Un GPU moderne de consommation courante calcule plusieurs milliards de hachages MD5 par seconde. Un attaquant disposant d'un matériel modeste peut tester l'intégralité des combinaisons alphanumériques jusqu'à 8 caractères en quelques heures.

Les rainbow tables amplifient encore ce problème. Il s'agit de tables précalculées qui établissent une correspondance entre des hachages et les mots de passe qui les ont produits. Pour des algorithmes rapides sans sel, retrouver un mot de passe courant à partir de son hachage peut se faire en quelques millisecondes, sans même avoir à calculer quoi que ce soit. Des bases de données de hachages MD5 de dizaines de milliards de mots de passe sont disponibles publiquement.

SHA-256 et SHA-512, souvent présentés à tort comme des alternatives, souffrent du même défaut fondamental : ils sont conçus pour être rapides. Ajouter un sel au hachage résout le problème des rainbow tables mais n'adresse pas la vitesse de calcul brute. Face à un GPU, même un mot de passe sélectionné avec soin ne résiste pas longtemps à une attaque par dictionnaire augmentée de règles de mutation.

Argon2id : le standard recommandé en 2026

Argon2 a remporté le Password Hashing Competition en 2015 et s'est imposé depuis comme la référence absolue. Il existe en trois variantes : Argon2d (résistant aux attaques GPU), Argon2i (résistant aux attaques par canaux auxiliaires) et Argon2id, hybride qui combine les protections des deux premières. Le NIST (SP 800-63B) et l'ANSSI recommandent Argon2id pour les nouvelles implémentations.

La force d'Argon2id réside dans ses trois paramètres configurables : le coût en mémoire (m), le nombre d'itérations (t) et le degré de parallélisme (p). En rendant le calcul intensive en mémoire, Argon2id pénalise les GPU et les circuits intégrés dédiés (ASIC) qui excellent dans les calculs massivement parallèles mais disposent d'une mémoire limitée par cœur. Un attaquant cherchant à paralléliser le cassage doit multiplier non seulement les unités de calcul, mais aussi la mémoire disponible.

Le sel est généré automatiquement par les bibliothèques conformes et encodé dans la chaîne de hachage résultante, qui inclut également l'algorithme, la version et les paramètres utilisés. Cette auto-description facilite la migration et la rotation des paramètres sans rupture de service.

bcrypt : encore viable dans certains cas ?

bcrypt, introduit en 1999, reste une option acceptable dans des contextes spécifiques. Son mécanisme de work factor permet d'augmenter progressivement le coût du calcul à mesure que la puissance des machines croît, sans invalider les hachages existants. Sa limitation principale est une contrainte sur la longueur des mots de passe : la plupart des implémentations tronquent silencieusement les entrées à 72 octets, ce qui peut surprendre avec des passphrases longues.

En 2026, un facteur de coût (cost) de 12 est le minimum raisonnable, 13 ou 14 étant préférable si la latence de l'authentification le permet. bcrypt conserve sa pertinence dans des environnements où les bibliothèques Argon2id ne sont pas disponibles ou dans des applications legacy où la migration progressive est préférable à une réécriture complète.

scrypt, autre algorithme memory-hard, est également une alternative sérieuse. Son avantage théorique sur bcrypt est sa résistance accrue aux ASIC, mais il est moins largement supporté et ses paramètres sont plus difficiles à calibrer correctement. Pour toute nouvelle implémentation, Argon2id reste le choix privilégié.

Paramètres recommandés par le NIST et l'ANSSI

Le calibrage des paramètres doit trouver l'équilibre entre sécurité et expérience utilisateur. Un hachage trop lent dégrade les performances de connexion ; trop rapide, il s'expose au cassage. La règle pratique est de viser un temps de calcul d'environ 300 à 500 millisecondes sur le serveur pour une authentification interactive.

• Argon2id : mémoire minimum 64 Mo (m=65536), iterations t=3, parallélisme p=4. Pour les systèmes avec davantage de ressources disponibles, monter à 128 Mo ou 256 Mo améliore significativement la résistance. Le NIST recommande d'augmenter ces paramètres au fil du temps à mesure que la puissance de calcul augmente.
• bcrypt : facteur de coût 12 minimum en 2026, 13 recommandé. Le recalibrer tous les deux à trois ans en fonction de l'évolution des benchmarks GPU disponibles publiquement.
• scrypt : paramètres N=2^17, r=8, p=1 comme point de départ. Ajuster N pour équilibrer mémoire et temps de calcul selon l'infrastructure.

Dans tous les cas, la longueur minimale requise pour les mots de passe doit être de 12 caractères, sans limite supérieure arbitraire. L'ANSSI recommande 12 caractères pour les comptes standards, davantage pour les comptes à privilèges élevés.

Un mot de passe bien haché reste souvent la dernière ligne de défense quand tous les autres contrôles ont été contournés. La qualité de cette défense se décide au moment du choix de l'algorithme, pas au moment de la fuite. L'étape suivante est de remplacer les mots de passe par des passkeys et d'éliminer ce risque à la source. Notre expertise en sécurité des authentifications peut vous accompagner dans cette transition.

Implémentations pratiques (Node.js, Python, Rust)

La règle d'or : ne jamais implémenter soi-même un algorithme de hachage de mots de passe. Utiliser exclusivement des bibliothèques auditées et maintenues activement.

En Node.js, la bibliothèque argon2 (package npm) expose une API simple qui gère automatiquement la génération du sel, l'encodage des paramètres et la vérification. Pour bcrypt, bcryptjs est une implémentation pure JavaScript portable, tandis que bcrypt s'appuie sur des bindings natifs plus performants. La vérification doit toujours utiliser la fonction de comparaison fournie par la bibliothèque, qui garantit une comparaison en temps constant pour prévenir les attaques temporelles.

En Python, la bibliothèque argon2-cffi est la référence pour Argon2id. Pour les applications Django, le backend de hachage Argon2 est disponible nativement depuis la version 2.0 et s'active avec un seul paramètre de configuration. bcrypt est disponible via le package éponyme. Passlib reste une option qui abstrait le choix de l'algorithme et facilite la migration.

En Rust, la crate argon2 (crate.io) est mature et bien maintenue. Elle s'intègre naturellement avec les frameworks web comme Axum ou Actix. Les garanties de sécurité mémoire de Rust sont particulièrement précieuses ici : l'absence de garbage collector évite que les mots de passe en clair ne persistent en mémoire plus longtemps que nécessaire, et l'utilisation de types effacés (Zeroize) garantit que les données sensibles sont bien supprimées après usage.

Un aspect souvent négligé est la rotation progressive des paramètres. Lorsque les recommandations évoluent, il n'est pas nécessaire de forcer tous les utilisateurs à changer leur mot de passe. La bonne pratique consiste à détecter, lors d'une connexion réussie, si le hachage stocké utilise des paramètres obsolètes, et à recalculer le hachage avec les nouveaux paramètres en profitant de la disponibilité momentanée du mot de passe en clair. Cette migration transparente s'effectue au rythme naturel des connexions. Une fois l'authentification réussie, la gestion sécurisée des tokens après authentification est l'étape suivante dans la chaîne de protection.