L'entropie : la vraie mesure de la force d'un mot de passe
Oubliez les barres de progression colorées des sites web qui vous disent si votre mot de passe est "faible", "moyen" ou "fort". Ces indicateurs sont souvent trompeurs, basés sur des heuristiques superficielles plutôt que sur la cryptographie. La vraie mesure de la force d'un mot de passe s'appelle l'entropie, et elle se calcule.
La formule mathématique
L'entropie d'un mot de passe est définie comme :
H = log₂(N^L)Où N est la taille du charset (l'ensemble des caractères possibles) et L est la longueur du mot de passe. Le résultat H est exprimé en bits. Plus le nombre de bits est élevé, plus le mot de passe est difficile à deviner par force brute.
Cette formule peut se simplifier :
H = L × log₂(N)Ce qui signifie que l'entropie croît linéairement avec la longueur, et logarithmiquement avec la taille du charset. C'est là que se cache la vérité contre-intuitive que beaucoup ignorent : la longueur fait croître l'entropie bien plus vite que la complexité.
Exemples chiffrés concrets
Voici quelques configurations courantes, avec leur entropie calculée :
| Configuration | Charset (N) | Longueur (L) | Entropie (bits) |
|---|---|---|---|
| 8 lettres minuscules | 26 | 8 | 37,6 bits |
| 8 chars alphanumériques | 62 | 8 | 47,6 bits |
| 8 chars tous types (ASCII imprimable) | 95 | 8 | 52,6 bits |
| 12 chars alphanumériques | 62 | 12 | 71,5 bits |
| 16 chars minuscules seulement | 26 | 16 | 75,2 bits |
| 16 chars tous types | 95 | 16 | 105,1 bits |
| 20 chars tous types | 95 | 20 | 131,4 bits |
La leçon frappante : 16 lettres minuscules aléatoires (75 bits) battent 8 caractères avec symboles (52 bits). Encore plus parlant : ajouter des majuscules et symboles à un mot de passe de 8 caractères n'apporte que 5 bits supplémentaires, quand passer à 9 caractères en apporte 6,6 bits avec le même charset. Le calcul est brutal. Voici comment implémenter ce calcul en JavaScript :
function passwordEntropy(length, charsetSize) {
// H = L * log2(N)
return length * Math.log2(charsetSize);
}
// Exemples
console.log(passwordEntropy(8, 26).toFixed(1)); // 37.6 bits (minuscules)
console.log(passwordEntropy(8, 95).toFixed(1)); // 52.6 bits (tous types)
console.log(passwordEntropy(16, 95).toFixed(1)); // 105.1 bits (recommandé)
console.log(passwordEntropy(20, 95).toFixed(1)); // 131.4 bits (très fort)Cette formule suppose que le mot de passe est généré aléatoirement avec un générateur cryptographiquement sûr (CSPRNG). Notre générateur de mots de passe utilise window.crypto.getRandomValues() à cet effet — si vous êtes curieux des détails CSPRNG, notre article sur le générateur de nombres aléatoires explique pourquoi l'aléa cryptographique est fondamentalement différent de Math.random().
Les attaques en pratique
Comprendre l'entropie ne suffit pas. Il faut aussi comprendre comment les attaquants s'y prennent pour casser des mots de passe — parce que toutes les attaques ne commencent pas par la force brute pure.
L'attaque par brute force
La méthode la plus naïve : essayer systématiquement toutes les combinaisons possibles. Pour un charset de 95 caractères et une longueur de 8, cela représente 95⁸ = 6 634 204 312 890 625 combinaisons (~6,6 quadrillions). Sur un cluster moderne de RTX 5090, en attaquant un hash MD5, on atteint environ 200 milliards d'essais par seconde. 6,6 quadrillions / 200 milliards = ~33 000 secondes, soit environ 9 heures. C'est déjà faisable pour un attaquant motivé, en 2026.
Mais cette vitesse s'effondre avec la longueur. Pour 12 caractères : 95¹² ≈ 5,4 × 10²³ combinaisons. Même à 200 milliards/sec, il faudrait 85 millions d'années. La brute force pure est donc inefficace au-delà de ~10-11 caractères sur un hash faible — ce qui explique pourquoi les attaquants utilisent des méthodes bien plus intelligentes.
L'attaque par dictionnaire
La plupart des mots de passe réels ne sont pas vraiment aléatoires. Ils sont dérivés de mots courants, de prénoms, de dates. Les attaquants le savent. La liste RockYou, issue d'une fuite de 2009, contient 14 millions de mots de passe réels utilisés à l'époque. En 2026, les bases de dictionnaire agrégées dépassent 10 milliards d'entrées.
Un outil comme Hashcat ou John the Ripper charge cette liste et tente chaque entrée contre le hash cible. Si votre mot de passe est password123, motdepasse, iloveyou, ou n'importe quel mot présent dans ces listes, il tombera en quelques secondes — peu importe sa "complexité" apparente.
L'attaque hybride et les règles Hashcat
L'attaque hybride combine dictionnaire et brute force : on prend un mot du dictionnaire et on lui ajoute des suffixes numériques ou des caractères spéciaux. Password → Password1, Password123, Password!, P@ssword.
Hashcat va plus loin avec son système de règles de transformation. Une règle simple peut transformer chaque entrée du dictionnaire par des patterns communs : MAY → M4y (substitution leetspeak), football → Football! (majuscule + point d'exclamation), ou encore inverser le mot et ajouter l'année en cours. Des packs de règles comme best64.rule ou OneRuleToRuleThemAll appliquent des milliers de transformations en parallèle, couvrant la quasi-totalité des "astuces" de mémorisation que les humains utilisent. Si vous avez remplacé les "e" par des "3" et les "a" par des "@", Hashcat le sait déjà.
Les tables rainbow (et pourquoi le sel les rend inutiles)
Avant que les GPU deviennent omniprésents, les attaquants utilisaient les tables rainbow : des structures précalculées de millions de paires (mot de passe → hash). Si le hash d'un mot de passe figure dans la table, la recherche est quasi instantanée. Une table MD5 pour les mots de passe jusqu'à 8 caractères alphanumériques pouvait tenir sur un disque dur et permettre de casser des mots de passe en secondes.
La contre-mesure s'appelle le sel (salt) : une valeur aléatoire unique, générée lors de la création du compte, concaténée au mot de passe avant de hacher. Le hash stocké devient hash(sel + mot_de_passe). Chaque compte a un sel différent, ce qui rend inutilisable toute table précalculée — il faudrait une table distincte pour chaque sel unique, ce qui est impossible en pratique. Le sel doit être d'au moins 128 bits, généré par un CSPRNG. Aujourd'hui, tout système correctement implémenté utilise un sel. Si vous voyez une fuite de données où les mots de passe sont des hashs MD5 sans sel, fuyez ce service.
Combien de temps tient un mot de passe ? Tableau de vérité 2026
Les chiffres ci-dessous sont basés sur une attaque Hashcat sur cluster de GPU haute performance (4x RTX 5090, ~300 milliards hash/sec pour MD5, beaucoup moins pour les algorithmes lents). Ces vitesses représentent le pire cas pour la victime : un attaquant avec des ressources significatives mais pas une agence nationale.
| Mot de passe | Entropie | MD5 / SHA-1 | SHA-256 | bcrypt (coût 12) | Argon2id |
|---|---|---|---|---|---|
password |
~0 (dictionnaire) | < 1 seconde | < 1 seconde | < 1 seconde | < 1 seconde |
| 8 chars aléatoires, minuscules | 37,6 bits | ~2 minutes | ~15 minutes | ~6 mois | Des années |
| 8 chars aléatoires, tous types | 52,6 bits | ~5 heures | ~2 jours | Des siècles | Des millénaires |
| 12 chars aléatoires, alphanum. | 71,5 bits | ~1 500 ans | ~25 000 ans | Astronomique | Astronomique |
| 16 chars aléatoires, tous types | 105,1 bits | Impossible | Impossible | Impossible | Impossible |
| Passphrase 6 mots EFF | 77,5 bits | Des millions d'années | Impossible pratiquement | Impossible | Impossible |
Le message essentiel de ce tableau : l'algorithme de hachage côté serveur importe autant que votre mot de passe. Un mot de passe de 8 caractères avec symboles tient 5 heures contre MD5 — ce qui est notoirement insuffisant en 2026. Le même mot de passe contre Argon2id correctement configuré tient des millénaires. Vous n'avez pas le contrôle sur l'algorithme utilisé par les sites ; c'est pourquoi l'unicité par site est non négociable.
La crise des hash faibles
MD5 et SHA-1 ne sont pas "faibles" dans le sens où ils seraient cassés cryptographiquement pour toutes les applications — mais ils sont totalement inadaptés au hachage de mots de passe. La raison est simple : ils ont été conçus pour être rapides. Un hash rapide est exactement ce dont un attaquant a besoin.
L'évolution des fonctions de hachage de mots de passe
La chronologie de cette guerre de vitesse :
- Avant 2000 : MD5 et SHA-1 utilisés naïvement. Les bases de données web stockent
MD5(password). Les tables rainbow les cassent en minutes dès que les GPU deviennent accessibles. - PBKDF2 (Password-Based Key Derivation Function 2) : introduit dans PKCS#5 en 2000, standardisé dans RFC 8018. Applique un hash (HMAC-SHA1/256) des milliers de fois de manière itérative, rendant chaque essai plus coûteux. NIST SP 800-63B recommande au moins 600 000 itérations avec PBKDF2-SHA256 en 2023. Problème : toujours parallélisable massivement sur GPU.
- bcrypt (1999) : conçu par Niels Provos et David Mazières spécifiquement pour les mots de passe. Utilise un facteur de coût ajustable. Résistant aux GPU car conçu pour les processeurs à mémoire lente. Limite à 72 bytes d'entrée utile.
- scrypt (2009) : ajoute la mémoire comme ressource coûteuse, en plus du temps CPU. Les ASIC et GPU n'ont pas facilement accès à de grandes quantités de mémoire rapide.
- Argon2 (2015) : vainqueur du Password Hashing Competition. Trois variantes : Argon2d (résistant GPU), Argon2i (résistant aux attaques par canaux auxiliaires), Argon2id (hybride recommandé). Paramètres configurables : mémoire, parallélisme, itérations.
Les paramètres OWASP recommandés en 2026
L'OWASP Password Storage Cheat Sheet (mise à jour 2025) recommande Argon2id comme premier choix avec ces paramètres minimaux :
Argon2id
Memory : 64 MB (65 536 KiB)
Iterations (time cost) : 3
Parallelism : 4
Output length : 32 bytesSi Argon2id n'est pas disponible dans votre stack, l'ordre de préférence OWASP est : Argon2id > scrypt > bcrypt > PBKDF2. MD5 et SHA-1 seuls sont inacceptables, quel que soit le contexte. SHA-256 seul l'est aussi — le "SHA" seul ne constitue pas un stockage sécurisé de mot de passe.
Charset : pourquoi les symboles ne font pas tout
Les politiques de mots de passe traditionnelles insistent : "au moins une majuscule, un chiffre, un symbole". Prenons le calcul au sérieux.
Comparez ces deux configurations :
| Configuration | N | L | Entropie |
|---|---|---|---|
| 12 chars alphanumérique (a-z, A-Z, 0-9) | 62 | 12 | 71,5 bits |
| 16 chars minuscules uniquement (a-z) | 26 | 16 | 75,2 bits |
Seize lettres minuscules aléatoires sont plus fortes que douze caractères alphanumériques. Et pourtant, la plupart des sites web valideraient le second et demanderaient à l'utilisateur d'ajouter "au moins un chiffre" au premier. Cette politique n'est pas de la sécurité — c'est du théâtre de la sécurité.
Le calcul réel qui devrait guider les politiques de mots de passe : log₂(charset_size) = bits_par_caractère. Pour les minuscules : 4,7 bits/char. Pour le charset complet ASCII imprimable (95 chars) : 6,57 bits/char. La différence par caractère est de moins de 2 bits. La longueur, elle, ajoute ce même delta à chaque caractère ajouté.
Les diceware passphrases
En 1995, Arnold Reinhold a décrit la méthode Diceware : choisir des mots aléatoires depuis une liste numérotée en lançant des dés physiques. Chaque mot est sélectionné par un code à 5 chiffres (de 11111 à 66666 dans l'espace d'un dé à 6 faces), correspondant à l'une des 7776 entrées de la liste (6⁵ = 7776).
L'entropie des passphrases Diceware EFF
La Electronic Frontier Foundation (EFF) a publié en 2016 sa propre liste de 7776 mots en anglais, soigneusement choisie pour être mémorisable et sans ambiguïtés. Le calcul d'entropie :
Entropie par mot = log₂(7776) ≈ 12,9 bits
4 mots : 4 × 12,9 ≈ 51,7 bits
5 mots : 5 × 12,9 ≈ 64,6 bits
6 mots : 6 × 12,9 ≈ 77,5 bitsL'argument XKCD #936 ("correct horse battery staple") a popularisé cette idée : quatre mots aléatoires créent un mot de passe avec environ 44 bits d'entropie (en supposant un dictionnaire de 2048 mots) — difficile à deviner, facile à retenir. La liste EFF officielle, plus grande (7776 mots), offre 51,7 bits pour 4 mots.
La distinction critique : les mots doivent être vraiment aléatoires. "Chien chat maison voiture" — quatre mots associatifs que vous avez choisis — n'a pas 51 bits d'entropie, parce que votre cerveau n'est pas aléatoire. Les dés physiques, ou un générateur CSPRNG, le sont. Notre générateur de mots de passe utilise window.crypto.getRandomValues() pour garantir cette propriété.
Quand utiliser une passphrase plutôt qu'un mot de passe ?
Une passphrase de 6 mots EFF (77 bits) est idéale pour votre mot de passe maître de gestionnaire : vous devez le taper régulièrement, le retenir sans aide, et il doit être très fort. Pour les mots de passe de sites web, un mot de passe aléatoire de 16+ caractères généré par votre gestionnaire est préférable — vous n'avez pas besoin de le retenir.
Le piège des "exigences" stupides
Le problème des politiques de mots de passe d'entreprise traditionnelles est bien documenté. Elles imposent typiquement : au moins une majuscule, un chiffre, un symbole — mais plafonnent à 16 caractères maximum. Elles exigent aussi un renouvellement forcé tous les 90 jours. Le résultat prévisible : les utilisateurs créent des mots de passe comme Janvier2026!, Fevrier2026!, Mars2026!.
Ces mots de passe respectent toutes les "exigences" et sont pourtant catastrophiquement prévisibles. Un attaquant qui connaît le pattern (et les patterns sont souvent devinables depuis des fuites précédentes) peut les casser avec une règle Hashcat en quelques secondes.
Ce que dit le NIST SP 800-63B
Le NIST Special Publication 800-63B, publié en 2017 et mis à jour en 2024, est le document de référence américain sur les identifiants numériques. Il dit, noir sur blanc :
- Longueur minimale de 8 caractères pour les mots de passe utilisateur. Au moins 64 caractères doivent être acceptés.
- Pas de règles de complexité obligatoires. Les politiques "1 majuscule, 1 chiffre, 1 symbole" ne sont pas recommandées car elles n'améliorent pas significativement la sécurité et poussent les utilisateurs vers des patterns prévisibles.
- Pas de rotation périodique obligatoire, sauf en cas de compromission avérée. Le renouvellement forcé tous les 90 jours réduit la sécurité en pratique.
- Vérification contre les listes de mots de passe compromis. Les services doivent vérifier les mots de passe choisis contre des bases de données de mots de passe leakés (comme HaveIBeenPwned).
L'ANSSI française (Agence Nationale de la Sécurité des Systèmes d'Information) émet des recommandations similaires dans son guide de gestion des mots de passe 2022 : longueur prioritaire sur la complexité, entropie calculable plutôt qu'heuristique.
Pwned passwords : ne JAMAIS utiliser un mot de passe déjà fuité
Troy Hunt a lancé HaveIBeenPwned en 2013. La base de données Pwned Passwords contient, en 2026, plus de 13 milliards de mots de passe issus de fuites réelles. Un mot de passe qui figure dans cette liste — même s'il est "fort" selon les heuristiques habituelles — est compromis par définition, parce que les attaquants l'ont dans leurs dictionnaires.
L'API k-anonymity : vérifier sans exposer
Le mécanisme de l'API Pwned Passwords garantit la confidentialité via le protocole k-anonymity :
1. Calculer SHA-1(votre_mot_de_passe) → ex: "5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8"
2. Envoyer seulement les 5 premiers chars à l'API : "5BAA6"
3. L'API retourne une liste de ~500 suffixes correspondants
4. Chercher localement si le suffixe complet ("1E4C9B93F3F0682250B6CF8331B7EE68FD8")
figure dans la liste
5. Votre mot de passe en clair n'a jamais quitté votre appareilCe protocole est élégant : même l'API ne peut pas savoir quel mot de passe vous vérifiez — elle reçoit seulement un préfixe parmi 2^20 préfixes possibles. Vous pouvez intégrer cette vérification dans votre générateur avec une simple requête fetch(). La règle est simple : si votre mot de passe apparaît dans cette base, régénérez-en un nouveau immédiatement, quelle que soit l'entropie théorique.
Le password spraying et les attaques en credential stuffing
Deux attaques méritent une mention spéciale, parce qu'elles n'ont rien à voir avec le cracking de hash et contournent toute la discussion sur l'entropie.
Le credential stuffing
En 2019, Disney+ a été lancé. Dans les heures suivant le lancement, des dizaines de milliers de comptes ont été compromis. L'attaque n'était pas technique : les attaquants avaient simplement testé, sur Disney+, des paires email/mot de passe issues d'autres fuites (LinkedIn 2012, Adobe 2013, Dropbox 2012). Les utilisateurs qui avaient réutilisé le même mot de passe sur ces services et Disney+ ont été immédiatement exposés.
C'est le credential stuffing : utiliser des credentials leakés d'un service A pour attaquer le service B. Les outils (Sentry MBA, OpenBullet) automatisent ces tentatives à grande échelle, en distribuant les requêtes via des proxies pour contourner les rate limits. Selon Cloudflare, plus de 20% du trafic de connexion sur internet serait du credential stuffing en 2024.
Le password spraying
Variante inverse : au lieu d'essayer de nombreux mots de passe sur un compte (ce qui déclenche les systèmes de verrouillage), on essaie un petit nombre de mots de passe très communs sur un grand nombre de comptes. En testant Printemps2026! sur 10 000 comptes d'une entreprise, l'attaquant reste sous les seuils de détection compte par compte, tout en compromettant statistiquement plusieurs utilisateurs.
La seule défense efficace contre ces deux attaques : un mot de passe unique par service. Si chaque compte a un mot de passe différent généré aléatoirement, ni le credential stuffing ni le password spraying ne peuvent capitaliser sur une fuite préexistante. C'est la raison fondamentale pour laquelle un gestionnaire de mots de passe — abordé en détail dans notre guide complémentaire sur les gestionnaires de mots de passe — n'est pas un luxe mais une nécessité.
Cas particuliers : PIN, mot de passe maître, code de récupération
Tous les "mots de passe" ne sont pas créés égaux. Le contexte d'utilisation détermine le niveau d'entropie nécessaire.
Le PIN à 4 chiffres
Un PIN de 4 chiffres n'a que log₂(10⁴) ≈ 13,3 bits d'entropie. Cela semble ridiculement faible — et ça l'est, si l'attaquant peut essayer des milliards de combinaisons à la seconde. Mais un PIN sur un téléphone ou une carte bancaire est protégé par un compteur d'essais matériel : après 3 à 10 tentatives incorrectes, le système se verrouille ou se détruit. Avec seulement 10 essais autorisés, même un PIN de 4 chiffres est statistiquement sûr (probabilité de deviner = 10 / 10 000 = 0,1%). La sécurité n'est pas dans l'entropie seule, mais dans le modèle de menace complet.
Le mot de passe maître de gestionnaire
C'est votre point de défaillance unique. Sans l'avantage d'un compteur de tentatives (si un attaquant obtient votre coffre-fort chiffré, il peut essayer hors ligne), l'entropie doit être maximale. Recommandation : passphrase de 6 mots EFF minimum (77 bits), plus si vous pouvez. C'est mémorisable, et c'est pratiquement incassable. Évitez tout pattern : pas de citation célèbre, pas de paroles de chanson, pas de mots liés à votre vie.
Les codes de récupération
La plupart des services 2FA proposent des codes de récupération à usage unique. Ces codes sont générés aléatoirement par le service et ont généralement une entropie très élevée (100+ bits pour des codes de 16+ caractères hexadécimaux). Ils servent de dernier recours si vous perdez votre second facteur. La règle : les imprimer, les stocker physiquement dans un endroit sûr (coffre-fort, chez un proche de confiance), et ne jamais les stocker numériquement en clair.
Le futur sans mot de passe : passkeys (WebAuthn / FIDO2)
La promesse d'un monde sans mots de passe n'est plus théorique. En 2026, Apple, Google et Microsoft ont toutes adopté les passkeys comme méthode d'authentification principale sur leurs plateformes.
Comment fonctionnent les passkeys
Une passkey repose sur la cryptographie asymétrique :
- Création : votre appareil génère une paire de clés (publique + privée). La clé publique est envoyée au site web et stockée. La clé privée ne quitte jamais votre appareil — elle est protégée par l'enclave sécurisée de votre téléphone ou ordinateur (Secure Enclave chez Apple, TPM chez Windows, Titan chez Android).
- Authentification : le site envoie un défi (challenge) aléatoire. Votre appareil le signe avec votre clé privée, après vérification de votre présence (biométrie ou PIN). Le site vérifie la signature avec votre clé publique. Si elle correspond, vous êtes authentifié.
- Ce qu'il n'y a pas : aucun mot de passe en transit, aucun secret à voler côté serveur, aucune possibilité de phishing (la signature est liée au domaine exact).
Le standard sous-jacent est WebAuthn (W3C) combiné avec le protocole FIDO2 de la FIDO Alliance. La biométrie (empreinte digitale, Face ID) ne quitte jamais l'appareil — elle sert uniquement à déverrouiller la clé privée localement.
État d'adoption en 2026
En 2026, les passkeys sont supportées par : Apple (iOS, macOS, iCloud Keychain), Google (Android, Chrome, Google Account), Microsoft (Windows Hello, comptes Microsoft), et un nombre croissant de services tiers (GitHub, PayPal, Adobe, Uber, X/Twitter). La transition est en cours mais n'est pas complète : de nombreux services anciens n'ont pas encore migré, et certains systèmes d'entreprise (Active Directory, legacy SAML) restent sur mots de passe pour encore plusieurs années.
La transition réaliste : un monde majoritairement passkey d'ici 2028-2030, avec des mots de passe persistant comme fallback sur les systèmes anciens. D'ici là, les bonnes pratiques de ce guide s'appliquent pleinement.
Conclusion : la synthèse des règles d'or
La cryptographie appliquée aux mots de passe n'est pas abstraite — elle donne des règles concrètes et mesurables :
- Entropie : visez au moins 80 bits pour les mots de passe courants, 100+ pour les mots de passe maîtres. Utilisez notre générateur de mots de passe qui calcule l'entropie en temps réel.
- Longueur d'abord : 16 caractères alphanumériques > 8 caractères avec tous les symboles. Toujours.
- Aléatoire vraiment aléatoire : uniquement via un CSPRNG. Votre cerveau n'est pas aléatoire.
- Unique par service : un mot de passe leaké d'un service ne doit compromettre aucun autre. Pas négociable.
- Vérification contre les fuites : HaveIBeenPwned, via l'API k-anonymity, avant d'adopter un nouveau mot de passe.
- Hachage côté serveur : vous n'avez pas le contrôle, mais vous pouvez fuir les services qui stockent des mots de passe en clair ou hachés MD5 (signe visible lors d'une réception de "mot de passe oublié" par email qui vous envoie le mot de passe en clair).
- Passphrase pour le mot de passe maître : 6 mots EFF minimum.
Si retenir tous ces mots de passe uniques vous semble impossible, c'est parce que ça l'est — et c'est précisément pour ça qu'un gestionnaire de mots de passe est la pièce manquante du puzzle. Pour tout savoir sur comment choisir et adopter un gestionnaire (Proton Pass, Bitwarden, Dashlane, NordPass), lisez notre guide complet des gestionnaires de mots de passe.