Générateur de Mots de Passe

Un générateur de mots de passe crée des mots de passe aléatoires et difficiles à deviner selon une longueur et des règles de caractères choisies. Un bon générateur utilise un hasard cryptographiquement sûr et combine majuscules, minuscules, chiffres et symboles seulement si le service cible les accepte. Des mots de passe forts réduisent les attaques par dictionnaire, force brute et credential stuffing, mais ne remplacent pas un gestionnaire, des mots de passe uniques par compte ni l’authentification multifactorielle. Les mots de passe très complexes ne doivent pas être mémorisés ni réutilisés; ils doivent être stockés de façon sûre. Pour les systèmes partagés, rotation, propriété et accès doivent être définis.

Le générateur de mots de passe puise son aléa dans crypto.getRandomValues(new Uint32Array(n)), qui remplit un tableau typé de valeurs pseudo-aléatoires cryptographiquement sûres issues du pool d'entropie du système d'exploitation (getrandom sur Linux, BCryptGenRandom sur Windows, SecRandomCopyBytes sur macOS/iOS). Il s'agit d'un CSPRNG tel que défini par l'API W3C Web Cryptography — contrairement à Math.random(), qui utilise dans V8 l'algorithme xorshift128+ et est explicitement documenté comme non cryptographique et prédictible à partir d'un petit échantillon de sorties. Le pool de caractères est assemblé à partir des classes sélectionnées par l'utilisateur : majuscules (26 lettres A-Z), minuscules (26 lettres a-z), chiffres (10 caractères 0-9) et symboles (32 caractères tirés de !@#$%^&*()_+-=[]{}|;:,.<>?), soit un pool maximum de 94 caractères. Un jeu de caractères personnalisé ou une liste d'exclusion (incluant un filtre de caractères ambigus supprimant i, I, l, L, 1, o, O, 0) affine encore le pool. Chaque caractère du mot de passe est sélectionné en prenant array[i] % pool.length, ce qui est uniformément distribué car la sortie du CSPRNG est uniforme sur 32 bits et le biais de modulo (|pool| ne divise pas 2^32 exactement) est négligeable pour des pools inférieurs à 256 caractères — le biais est inférieur à 0,00000006 %, bien en deçà de toute préoccupation pratique. La force du mot de passe est mesurée par la taille de l'espace de recherche : pour un pool de taille C et une longueur L, le nombre de mots de passe possibles est C^L. L'entropie en bits est log2(C^L) = L × log2(C). Pour un mot de passe de 16 caractères avec les quatre classes activées (C=94), cela donne 94^16 ≈ 4,4 × 10^31 combinaisons, soit environ 105 bits d'entropie. À un taux d'attaque hypothétique de 10^12 tentatives par seconde (environ le débit d'un grand cluster GPU contre un hash rapide comme NTLM), la recherche exhaustive prendrait approximativement 4,4 × 10^19 secondes — bien plus que l'âge de l'univers. Ce modèle suppose que l'attaquant doit tester chaque combinaison (pas de raccourcis basés sur dictionnaire ou motifs) et que le mot de passe est haché avec un algorithme lent et salé comme bcrypt ou Argon2id plutôt que stocké en texte clair. NIST SP 800-63B recommande un minimum de 8 caractères pour les mots de passe choisis par l'utilisateur et au moins 6 caractères générés aléatoirement pour les identifiants machine, avec documentation du jeu de caractères. La plage de longueur du générateur, de 4 à 64 caractères, couvre tout, des codes PIN aux identifiants machine à haute entropie. L'option « commencer par une lettre » garantit que le premier caractère est tiré de [A-Za-z], ce qui satisfait les systèmes legacy exigeant que les mots de passe commencent par une lettre.

• Source CSPRNG : crypto.getRandomValues() puise l'entropie dans le CSPRNG du noyau du système d'exploitation (getrandom/BCryptGenRandom/SecRandomCopyBytes) — contrairement à Math.random() (xorshift128+), il n'est pas prédictible, pas initialisable par la page, et adapté à la génération d'identifiants.
• Mathématiques de l'espace de caractères : avec les quatre classes activées, la taille du pool est de 94 ; l'entropie par caractère est log2(94) ≈ 6,55 bits. Un mot de passe de 16 caractères porte environ 105 bits d'entropie ; doubler la longueur à 32 porte ce chiffre à environ 210 bits.
• Sélection par modulo : array[i] % pool.length mappe la sortie CSPRNG 32 bits vers un indice de caractère — le biais est inférieur à 6 × 10^-8 % pour des pools de moins de 256 caractères, ce qui le rend cryptographiquement négligeable.
• Modèle de résistance à la force brute : à 10^12 tentatives/seconde (échelle de cluster GPU), un mot de passe de 16 caractères avec 94 symboles prendrait environ 10^19 secondes pour être épuisé — mais cela suppose un hash rapide ; bcrypt avec un facteur de coût de 12 ramène l'attaquant à environ 10^4 tentatives/seconde, rendant même les mots de passe de 8 caractères résilients.
• Exclusion des caractères ambigus : le filtre supprime {i, I, l, L, 1, o, O, 0} (8 caractères) — cela réduit le pool de 94 à 86, coûtant environ 0,6 bit d'entropie par caractère, ce qui est acceptable au regard du gain d'utilisabilité dans les scénarios de transcription manuelle.
• Alignement NIST SP 800-63B : la norme exige un minimum de 6 caractères choisis aléatoirement pour les secrets générés par machine et recommande de documenter l'espace de caractères — les préréglages du générateur (Simple 8 car., Fort 20 car.) correspondent à différents niveaux d'assurance.
• Historique localStorage : les 10 derniers mots de passe générés sont persistés dans window.localStorage, qui est limité à l'origine et au profil du navigateur — effacer l'historique les supprime du stockage, mais un outil de forensique au niveau disque pourrait les récupérer car localStorage est stocké sous forme de base de données SQLite en texte clair dans le répertoire du profil du navigateur.