Une bonne politique de mot de passe ne consiste pas à imposer le plus grand nombre possible de règles. Elle cherche surtout à rendre les secrets difficiles à deviner, uniques et praticables pour les utilisateurs.
La longueur compte beaucoup
Une phrase de passe longue et imprévisible peut être préférable à une chaîne courte truffée de substitutions prévisibles. Le générateur de mot de passe aide à produire un secret aléatoire lorsque l’utilisateur n’a pas besoin de le mémoriser.
Un indicateur de robustesse reste une estimation
Le testeur de robustesse donne un retour pratique sur longueur et composition, mais aucun score local ne peut connaître tous les dictionnaires, toutes les fuites ou le contexte d’un attaquant.
Un mot de passe fort déjà compromis ou réutilisé sur plusieurs services reste dangereux.
Éviter les règles qui dégradent les comportements
Forcer des changements très fréquents sans incident peut encourager des variantes prévisibles. Imposer systématiquement majuscule, chiffre et symbole ne garantit pas une forte entropie. Une politique moderne privilégie généralement une longueur suffisante, le blocage des secrets courants ou compromis et l’authentification multifacteur lorsque le risque le justifie.
Le générateur de politique de mot de passe permet de formaliser ces choix pour les documenter et les adapter à une application.
Côté serveur, ne stockez pas le mot de passe en clair
Le stockage des mots de passe nécessite des fonctions dédiées et salées conçues pour résister aux attaques par essais massifs. Un hash générique rapide n’est pas automatiquement un bon mécanisme de stockage de mots de passe.
Le guide Hash, intégrité et comparaison explique cette distinction sans transformer un outil de hash générique en gestionnaire d’identifiants.
Longueur, imprévisibilité et entropie
La robustesse dépend surtout de l’espace de recherche qu’un attaquant doit explorer. Ajouter un caractère à un secret réellement aléatoire augmente cet espace ; ajouter systématiquement 1! à un mot courant beaucoup moins. C’est pourquoi les règles mécaniques de composition peuvent produire des mots de passe conformes mais prévisibles.
Pour un secret généré et stocké dans un gestionnaire, une chaîne longue et aléatoire est idéale. Pour un secret mémorisé, une phrase de passe suffisamment longue peut offrir un meilleur compromis entre robustesse et utilisabilité.
Un mot de passe doit surtout être unique
La réutilisation transforme la compromission d’un service en risque pour les autres. Une politique utile encourage donc l’utilisation d’un gestionnaire de mots de passe et interdit les secrets connus comme compromis lorsque l’infrastructure permet de les détecter.
Le générateur de mot de passe produit des secrets indépendants ; le testeur de robustesse aide à repérer certaines faiblesses évidentes, mais aucun score ne remplace l’unicité.
MFA et passkeys changent le modèle de risque
L’authentification multifacteur ajoute une barrière lorsque le mot de passe est compromis. Toutes les méthodes MFA ne résistent pas de la même façon au phishing, mais une seconde preuve bien conçue réduit fortement certains scénarios d’attaque.
Les passkeys reposent sur des clés cryptographiques plutôt que sur un secret partagé mémorisé. Elles peuvent réduire les risques liés au phishing et à la réutilisation. Elles ne rendent pas immédiatement les politiques de mots de passe inutiles pour toutes les applications, mais elles font partie des options modernes à considérer.
Stockage serveur : utiliser une fonction dédiée
Un serveur ne devrait pas avoir besoin de retrouver le mot de passe original. Il stocke normalement le résultat d’une fonction de dérivation de mot de passe avec un sel unique. Des fonctions comme Argon2id, scrypt ou bcrypt sont conçues pour rendre les essais coûteux, contrairement à un hash générique rapide tel que SHA-256 utilisé seul.
Le sel n’a pas besoin d’être secret ; il empêche notamment que deux utilisateurs ayant le même mot de passe obtiennent automatiquement la même empreinte et complique l’utilisation de tables précalculées. Selon l’architecture, un secret serveur supplémentaire (« pepper ») peut compléter le dispositif, mais il ne remplace pas une fonction adaptée.
Politique utilisateur : privilégier les règles explicables
Fixez une longueur minimale raisonnable, acceptez les mots de passe longs, évitez les changements périodiques sans raison, bloquez les secrets manifestement faibles ou compromis et permettez le collage afin de ne pas gêner les gestionnaires de mots de passe.
Le générateur de politique de mot de passe sert à formaliser ces choix. Une politique doit rester compatible avec le niveau de risque de l’application : un espace administratif sensible n’a pas les mêmes exigences qu’un service sans données importantes.
Après une compromission
Lorsqu’un mot de passe ou la base d’identifiants est suspecté d’être compromis, la réponse ne consiste pas seulement à augmenter la complexité minimale. Il faut invalider les accès concernés, renouveler les secrets, examiner les sessions actives et comprendre la cause de l’incident.
C’est aussi pour cette raison qu’une politique de mot de passe n’est qu’une couche de la sécurité Web globale.
