Le bon générateur, langage . Tous les générateurs de mots de passe ne se valent pas — et le langage dans lequel votre coffre est écrit n'est pas un détail d'ingénieur. Décryptage de l'entropie, des modes de génération, et de pourquoi Rust s'impose sous le capot. Quand un gestionnaire « génère un mot de passe fort », deux questions se posent : est-il vraiment imprévisible (la qualité de l'aléatoire), et que devient-il en mémoire une fois affiché ? La première relève des modes de génération. La seconde, du langage qui fait tourner l'application. Cet article couvre les deux. ~100 bits mot de passe aléatoire de 16 caractères (très fort) ~77 bits passphrase Diceware de 6 mots (EFF) 12,9 bits d'entropie ajoutés par mot Diceware (liste 7 776 mots) Entropie : la seule mesure qui compte La force d'un mot de passe ne se mesure pas à sa « complexité » ressentie, mais à son entropie : le nombre de bits d'incertitude pour un attaquant. Plus il y a de combinaisons possibles, plus le coût d'une attaque par force brute explose. Un mot de passe de 16 caractères tirés de tout l'alphabet ASCII atteint environ 100 bits — du domaine du « très fort ». Point crucial souvent oublié : l'entropie ne vaut que si la source d'aléatoire est un CSPRNG (générateur pseudo-aléatoire cryptographiquement sûr). Un Math.random() classique est prévisible et disqualifie tout le reste. Les bonnes implémentations lisent l'entropie du système d'exploitation : /dev/urandom ou getrandom(2) sous Unix, CNG sous Windows. Quatre familles de générateurs Un bon gestionnaire ne propose pas « un » générateur, mais plusieurs modes adaptés à l'usage. La règle : la mémorabilité se paie en longueur . Voici les quatre familles, du plus dense au plus humain. Le bon réflexe : adapter l'entropie à l'usage Pour un compte web protégé par une page de connexion limitée en débit, l'attaquant est bridé à quelques centaines d'essais par seconde : même 50 bits tiennent des temps géologiques. La sur-entropie n'a de sens que pour les secrets hors ligne (clé de chiffrement, seed de portefeuille crypto), où l'attaque peut être massivement parallélisée. Pour ces secrets de très haute valeur, rouler de vrais dés physiques (Diceware au sens propre) reste l'option ultime : elle élimine toute dépendance à la qualité du CSPRNG ou à un navigateur compromis. Pourquoi Rust change la donne Générer un bon mot de passe, c'est la moitié du travail. L'autre moitié : ne pas le laisser traîner . Une fois affiché ou déchiffré, votre mot de passe vit en mémoire vive — et c'est là que le langage de l'application devient déterminant. Microsoft a rapporté que 70 % des vulnérabilités de sécurité qu'elle rencontre sont des bugs mémoire (buffer overflow, use-after-free, etc.). Google a observé la même proportion sur Chrome et Android. Ce sont précisément ces classes de failles que Rust élimine à la compilation , via son modèle de propriété ( ownership ) et d'emprunt ( borrowing ), sans ramasse-miettes. Les chiffres de Google sont éloquents : les vulnérabilités mémoire d'Android sont tombées de 223 en 2019 à moins de 50 en 2024 , passant sous la barre des 20 % du total pour la première fois. Le nouveau code Rust affiche une densité de failles mémoire jusqu'à 1000× inférieure au code C/C++ historique, avec en prime 4× moins de rollbacks et 25 % de temps de revue en moins. 1. Sécurité mémoire sans ramasse-miettes. Des langages comme Java ou Python sont mémoire-sûrs, mais leur garbage collector libère la mémoire de façon non déterministe : un secret peut y survivre indéfiniment, exposé à un memory dump ou une attaque cold-boot. Rust libère la mémoire de façon déterministe, dès que la donnée n'est plus utilisée. 2. Effacement explicite avec zeroize . Rust ne garantit pas que la mémoire libérée soit écrasée. La crate zeroize comble ce trou : en enveloppant un secret dans Zeroizing , on garantit son écrasement par des zéros — via une écriture volatile que le compilateur ne peut pas optimiser — au moment exact où il sort de portée. 3. Un système de types qui force le bon usage de la crypto. Le système de types strict de Rust permet de circonscrire comment une donnée sensible peut être utilisée — et combien de fois. On peut par exemple modéliser une clé qui ne peut être employée qu'une seule fois, le compilateur refusant tout réemploi. Honnêteté technique : Rust n'est pas une baguette magique Le code unsafe et les dépendances tierces restent des surfaces d'attaque — Google a d'ailleurs corrigé une faille (CVE-2025-48530) dans un bloc unsafe d'un parseur Rust avant toute mise en production. La sécurité mémoire est une couche , pas une fin en soi : elle se combine à une défense en profondeur (KDF robuste comme Argon2id, architecture zero-knowledge, auto-verrouillage, MFA). Ce qu'il faut exiger d'un gestionnaire Au moment de choisir — ou d'évaluer — un gestionnaire de mots de passe, quatre questions concrètes : 1. Le générateur s'appuie-t-il sur un CSPRNG système , et affiche-t-il l'entropie en bits ? 2. Propose-t-il un mode passphrase Diceware/EFF pour le mot de passe maître ? 3. La génération est-elle locale (client-side) , sans transit par un serveur ? 4. Le cœur sensible est-il écrit dans un langage mémoire-sûr avec effacement explicite des secrets ? Une génération sûre. Un coffre conçu pour durer. Mots de passe à haute entropie, passphrases mémorisables, et un cœur taillé pour la sécurité mémoire. Contenu informatif à vocation pédagogique. Les statistiques citées (Google/Android, Microsoft, Diceware/EFF) proviennent des sources listées ci-dessus. Les exemples de code Rust sont illustratifs et simplifiés.