Recommandations NIST 2025 sur les mots de passe : ce qui a changé
Par CaptainDNS
Publié le 20 février 2026
- Le NIST interdit désormais l'expiration périodique des mots de passe sauf en cas de compromission avérée
- Les règles de complexité (majuscule + chiffre + symbole) sont abandonnées : elles dégradent la sécurité en pratique
- Minimum 8 caractères obligatoires, 15 recommandés, et les systèmes doivent accepter au moins 64 caractères
- Chaque mot de passe doit être vérifié contre une base de secrets compromis (type Have I Been Pwned) avant acceptation
- Les indices de mot de passe et questions secrètes sont interdits comme mécanismes de récupération
Pendant des années, les politiques de mots de passe en entreprise suivaient la même recette : 8 caractères minimum, une majuscule, un chiffre, un symbole, et changement tous les 90 jours. Résultat : des utilisateurs qui choisissent Printemps2025! en janvier et Ete2025! en avril. Le NIST a officiellement reconnu que cette approche produit des mots de passe plus faibles, pas plus forts.
La révision 4 du SP 800-63B, publiée en 2024 et applicable dès 2025, renverse la plupart de ces pratiques. Ce document est la référence fédérale américaine pour l'authentification numérique, mais son influence dépasse largement les frontières : ANSSI, BSI et OWASP alignent progressivement leurs recommandations.
Cet article décrypte les changements concrets, explique la logique derrière chaque décision du NIST, et fournit un plan d'action pour mettre votre politique de mots de passe en conformité. Pour tester immédiatement la robustesse d'un mot de passe, utilisez notre générateur de mots de passe avec son indicateur de force en temps réel.
Ce que dit le NIST SP 800-63B-4
Le SP 800-63B fait partie de la suite NIST SP 800-63 (Digital Identity Guidelines), qui couvre l'ensemble du cycle de vie de l'identité numérique. La révision 4 remplace la version 3 de 2017 et introduit des changements majeurs dans la section dédiée aux "Memorized Secrets" (mots de passe et phrases de passe).
Portée du document
Le SP 800-63B s'adresse aux fournisseurs de services d'authentification (CSP, Credential Service Providers) et aux vérificateurs. Il définit trois niveaux d'assurance (AAL1, AAL2, AAL3), chacun avec des exigences croissantes. Les recommandations sur les mots de passe s'appliquent principalement au niveau AAL1 (authentification par facteur unique) et sont reprises comme base aux niveaux supérieurs.
Les 8 changements majeurs
Le tableau suivant résume les règles qui changent entre la version 3 (2017) et la version 4 (2024/2025) :
| Règle | SP 800-63B-3 (2017) | SP 800-63B-4 (2025) |
|---|---|---|
| Longueur minimale | 8 caractères | 8 obligatoire, 15 recommandé |
| Longueur maximale | Non spécifiée | 64 caractères minimum supporté |
| Règles de complexité | Déconseillées | Interdites (SHALL NOT) |
| Rotation périodique | Déconseillée | Interdite sauf compromission |
| Vérification compromis | Recommandée | Obligatoire (SHALL) |
| Indices de mot de passe | Non mentionnés | Interdits |
| Questions secrètes | Déconseillées | Interdites |
| Tous les caractères Unicode | Recommandé | Obligatoire |
Le passage de "SHOULD NOT" (déconseillé) à "SHALL NOT" (interdit) est significatif : ce n'est plus une recommandation, c'est une exigence de conformité.
Pourquoi le NIST abandonne la rotation obligatoire ?
La rotation périodique des mots de passe est la règle la plus controversée en sécurité informatique. Le NIST l'interdit désormais explicitement, et la raison est empirique.
Le problème documenté
Des études menées à l'Université de Caroline du Nord (Chappell et al.) ont montré que lorsque les utilisateurs sont contraints de changer régulièrement leur mot de passe, ils adoptent des schémas prévisibles :
- Incrémentation :
Motdepasse1→Motdepasse2→Motdepasse3 - Rotation saisonnière :
Hiver2024!→Printemps2025! - Transformation minimale :
MonChat$→MonChat$1→MonChat$12
Un attaquant qui obtient un ancien mot de passe peut deviner le suivant avec moins de 5 tentatives dans 41 % des cas. La rotation n'ajoute pas de sécurité, elle encourage la prévisibilité.
La nouvelle règle
Le mot de passe ne doit être changé que dans deux cas :
- Compromission avérée : le mot de passe apparaît dans une base de données piratée
- Demande de l'utilisateur : changement volontaire
Les administrateurs doivent supprimer toute politique d'expiration automatique (90 jours, 180 jours, annuelle). Le système doit néanmoins surveiller activement les bases de compromission et forcer un changement si le mot de passe actuel y apparaît.
Pourquoi les règles de complexité sont contre-productives ?
Exiger "au moins une majuscule, un chiffre et un symbole" semble logique sur le papier. En pratique, ça produit l'effet inverse.
L'effet pervers mesuré
Quand un système impose des règles de composition, les utilisateurs convergent vers les mêmes stratégies :
- Majuscule en première position (95 % des cas)
- Chiffres à la fin (89 % des cas)
- Symbole :
!ou@(78 % des cas)
Password1! satisfait toutes les règles de complexité classiques. Il est craqué en moins d'une seconde par tout outil de force brute qui teste les patterns courants. L'entropie théorique d'un mot de passe contraint est plus élevée, mais l'entropie réelle chute parce que les humains sont prévisibles.
Ce que le NIST recommande à la place
La longueur est le facteur dominant. Un mot de passe de 15 caractères aléatoires sans contrainte de composition offre plus d'entropie qu'un mot de passe de 8 caractères respectant toutes les règles de complexité. Le NIST demande aux systèmes de :
- Accepter tous les caractères imprimables ASCII et Unicode (espaces inclus)
- Ne pas imposer de règles de composition
- Supporter au minimum 64 caractères (pour permettre les phrases de passe)
- Normaliser les entrées Unicode (NFKC ou NFKD) pour éviter les problèmes d'encodage
Vérification contre les bases de mots de passe compromis
C'est le changement le plus technique. Chaque mot de passe choisi par un utilisateur doit être vérifié contre une liste de secrets compromis avant d'être accepté.
Comment implémenter la vérification ?
Le NIST ne prescrit pas une implémentation spécifique, mais la méthode la plus courante utilise le service Have I Been Pwned (HIBP) de Troy Hunt :
- Le système calcule le hash SHA-1 du mot de passe candidat
- Il envoie les 5 premiers caractères du hash à l'API HIBP (k-anonymity)
- L'API retourne tous les hash correspondants
- Le système vérifie localement si le hash complet est dans la liste
Ce mécanisme préserve la confidentialité : le mot de passe n'est jamais transmis en clair ni sous forme de hash complet. L'API HIBP contient plus de 900 millions de mots de passe uniques issus de fuites réelles.
Quand vérifier ?
| Moment | Obligatoire | Recommandé |
|---|---|---|
| Création de compte | Oui | - |
| Changement de mot de passe | Oui | - |
| Connexion | - | Oui (vérification périodique) |
Si le mot de passe est trouvé dans la base de compromission, le système doit le refuser avec un message clair expliquant pourquoi et invitant l'utilisateur à en choisir un autre.
Ce que le NIST interdit explicitement
Au-delà des changements majeurs, plusieurs pratiques sont désormais formellement interdites :
Indices de mot de passe
Les champs "indice" qui affichent un rappel en cas d'oubli sont interdits. Ils exposent des informations qui aident un attaquant à deviner le mot de passe. Un indice comme "nom de mon chat + année" réduit l'espace de recherche à quelques milliers de combinaisons.
Questions secrètes
"Quel est le nom de jeune fille de votre mère ?" ou "Dans quelle ville êtes-vous né ?" : ces questions dites de knowledge-based authentication (KBA) sont interdites comme seul facteur de récupération. Les réponses sont souvent trouvables sur les réseaux sociaux ou dans des bases de données publiques.
Troncature du mot de passe
Un système ne doit jamais tronquer le mot de passe à une longueur fixe avant le hachage. Si un utilisateur saisit 40 caractères, les 40 caractères doivent être pris en compte. La troncature réduit silencieusement l'entropie et crée un faux sentiment de sécurité.
Hachage sans sel
Le NIST exige que les mots de passe soient stockés avec une fonction de hachage résistante (bcrypt, scrypt, Argon2id ou PBKDF2) et un sel unique par utilisateur. SHA-256 seul n'est pas acceptable : il est trop rapide et vulnérable aux attaques par tables arc-en-ciel.
Comparaison NIST, OWASP, ANSSI
Le NIST n'est pas la seule référence. Voici comment ses recommandations se comparent aux autres standards majeurs :
| Critère | NIST SP 800-63B-4 | OWASP ASVS 4.0 | ANSSI (2021) |
|---|---|---|---|
| Longueur min. | 8 (15 recommandé) | 12 | 12 (16 pour admin) |
| Longueur max. supportée | 64+ | 128 | Non spécifié |
| Complexité | Interdite | Déconseillée | Acceptée sous conditions |
| Rotation | Interdite sauf compromission | Déconseillée | 1 an max |
| Vérification compromis | Obligatoire | Recommandée | Non mentionnée |
| MFA | Obligatoire AAL2+ | Obligatoire niv. 2+ | Recommandé |
| Questions secrètes | Interdites | Interdites | Non mentionnées |
Les trois référentiels convergent sur les principes fondamentaux (longueur > complexité, pas de rotation inutile) mais divergent sur le niveau d'exigence. L'ANSSI reste plus conservatrice sur la complexité et la rotation. L'OWASP est plus strict sur la longueur minimale.
🎯 Plan de mise en conformité
Pour les administrateurs système et RSSI qui doivent adapter leur politique :
- Supprimez l'expiration périodique : désactivez les politiques de changement à 90/180 jours dans Active Directory, LDAP ou votre IAM. Configurez la surveillance des compromissions à la place
- Retirez les règles de composition : supprimez les exigences "majuscule + chiffre + symbole". Augmentez la longueur minimale à 15 caractères et le maximum supporté à au moins 64
- Intégrez la vérification HIBP : implémentez la vérification k-anonymity à la création et au changement de mot de passe. Utilisez un générateur de hash pour vérifier vos implémentations SHA-1
- Acceptez tous les caractères : Unicode complet, espaces inclus. Appliquez la normalisation NFKC avant hachage
- Déployez le MFA : le mot de passe seul ne suffit pas. FIDO2/WebAuthn pour les comptes critiques, TOTP au minimum pour les autres
- Documentez votre politique : créez une politique écrite alignée sur le SP 800-63B-4 et communiquez les changements aux utilisateurs. Expliquez pourquoi ils n'auront plus à changer leur mot de passe régulièrement
FAQ
Qu'est-ce que le NIST SP 800-63B ?
Le NIST SP 800-63B est un document de référence publié par le National Institute of Standards and Technology (NIST) américain. Il fait partie de la suite Digital Identity Guidelines et couvre spécifiquement l'authentification et la gestion du cycle de vie des identifiants. La révision 4, publiée en 2024, est la version en vigueur et apporte des changements significatifs aux recommandations sur les mots de passe.
Faut-il encore changer son mot de passe régulièrement ?
Non. Le NIST interdit explicitement l'expiration périodique des mots de passe (SHALL NOT). Un mot de passe ne doit être changé que s'il est compromis (présent dans une base de données piratée) ou si l'utilisateur le demande volontairement. Les études montrent que le changement obligatoire pousse les utilisateurs vers des mots de passe prévisibles et plus faibles.
Les règles de complexité sont-elles toujours nécessaires ?
Non. Le NIST interdit les règles de composition ("au moins une majuscule, un chiffre, un symbole"). Ces règles produisent des patterns prévisibles (majuscule au début, chiffres à la fin, symbole !) qui réduisent l'entropie réelle. La longueur est le facteur dominant : un mot de passe long et aléatoire est plus sûr qu'un mot de passe court et "complexe".
Quelle longueur minimale pour un mot de passe en 2025 ?
Le NIST impose un minimum de 8 caractères et recommande 15. L'OWASP et l'ANSSI recommandent 12. En pratique, visez 15+ caractères pour les comptes utilisateurs et 20+ pour les comptes administrateurs. Les systèmes doivent accepter au minimum 64 caractères pour permettre l'usage de phrases de passe.
Comment vérifier si un mot de passe est compromis ?
Utilisez le protocole k-anonymity avec l'API Have I Been Pwned : hachez le mot de passe en SHA-1, envoyez les 5 premiers caractères du hash à l'API, et vérifiez si le hash complet apparaît dans les résultats. Le mot de passe n'est jamais transmis en clair. Cette vérification doit être effectuée à la création de compte et à chaque changement de mot de passe.
Le NIST s'applique-t-il en dehors des États-Unis ?
Le SP 800-63B est une norme fédérale américaine, mais son influence est mondiale. L'OWASP s'en inspire directement, le BSI allemand et l'ANSSI française alignent progressivement leurs recommandations. Pour les entreprises internationales ou celles qui traitent des données de citoyens américains, suivre le NIST est un standard de facto, même sans obligation légale directe.
Quel algorithme de hachage utiliser pour stocker les mots de passe ?
Le NIST recommande Argon2id, bcrypt, scrypt ou PBKDF2, avec un sel unique par utilisateur. SHA-256 ou MD5 seuls sont inacceptables : ils sont trop rapides et vulnérables aux attaques par tables arc-en-ciel et force brute GPU. Argon2id est le choix recommandé par l'OWASP en 2025, avec des paramètres de mémoire et de temps adaptés à votre infrastructure.
Glossaire
- SP 800-63B : Special Publication du NIST définissant les exigences d'authentification numérique, partie B (Authentication and Lifecycle Management). La révision 4 (2024) est la version en vigueur.
- AAL (Authentication Assurance Level) : niveau d'assurance de l'authentification défini par le NIST, de AAL1 (facteur unique) à AAL3 (matériel cryptographique résistant au phishing).
- k-anonymity : technique cryptographique permettant de vérifier si une donnée appartient à un ensemble sans révéler la donnée elle-même. Utilisée par Have I Been Pwned pour la vérification de mots de passe.
- Sel (salt) : valeur aléatoire unique ajoutée au mot de passe avant hachage, empêchant les attaques par tables précalculées (rainbow tables).
- Argon2id : fonction de hachage de mots de passe gagnante du Password Hashing Competition (2015), résistante aux attaques GPU et ASIC grâce à sa consommation mémoire configurable.
Vérifiez la robustesse de vos mots de passe maintenant : testez si vos URLs sont exploitées par le phishing avec notre détecteur de phishing, un complément essentiel à toute politique de mots de passe solide.
📚 Guides sécurité des mots de passe connexes
- Passkeys vs mots de passe : faut-il abandonner ses mots de passe en 2025 ?
- Phrase de passe vs mot de passe : qu'est-ce qui est vraiment plus sûr ?
