Générateur groupé de mots de passe, gratuit

Générez plusieurs mots de passe robustes en une seule fois. Personnalisez le nombre, la longueur et les caractères, puis téléchargez en fichier texte.

Mots de passe générés localement sur votre appareil
Cliquez sur « Générer les mots de passe » pour commencer

    Génération groupée de mots de passe

    Cet outil génère plusieurs mots de passe cryptographiquement robustes en une seule opération. Parfait pour préparer des listes pour l'accueil d'une équipe, la création en masse de comptes ou la gestion d'inventaires de mots de passe. Chaque mot de passe est produit via le générateur aléatoire intégré du navigateur.

    Niveaux de robustesse

    Questions fréquentes

    Ces mots de passe sont-ils vraiment aléatoires ?

    Oui. Les mots de passe sont générés avec window.crypto.getRandomValues(), qui fournit des valeurs aléatoires cryptographiquement sûres, adaptées aux usages de sécurité.

    Puis-je générer plus de 100 mots de passe ?

    L'outil limite la génération à 100 à la fois pour éviter de ralentir le navigateur. Générez plusieurs lots séparément si nécessaire.

    Comment stocker le fichier téléchargé ?

    Conservez le fichier .txt dans un emplacement sécurisé, de préférence chiffré. Ne le committez jamais dans un dépôt de code ni ne le partagez via des canaux non sécurisés. Supprimez-le après la distribution aux utilisateurs.

    D'où viennent les bons nombres aléatoires

    Un ordinateur est, par conception, déterministe. À entrées identiques et code identique, il produit les mêmes sorties à chaque fois. C'est exactement la propriété que l'on attend d'un processeur faisant tourner un tableur, et exactement celle que l'on ne veut pas d'un générateur de mots de passe. Si un attaquant peut reproduire la séquence de valeurs qu'a émises le générateur, il peut reproduire chaque mot de passe que celui-ci a jamais produit.

    Le générateur collecte donc de l'« entropie » (un signal physique imprévisible venu de l'extérieur du programme) et s'en sert pour amorcer un algorithme appelé CSPRNG (générateur de nombres pseudo-aléatoires cryptographiquement sûr). Le « pseudo » est honnête : les bits sont produits par un algorithme, et non par la physique. Le « cryptographiquement sûr » signifie que même un attaquant qui observe une longue série de sorties passées ne peut pas prédire l'octet suivant mieux que le hasard. Theodore Ts'o a implémenté /dev/random dans le noyau Linux en 1994, et macOS, les BSD, Solaris et Windows (avec BCryptGenRandom) ont tous adopté des interfaces équivalentes. En coulisses, ils mélangent toutes les sources plausibles de gigue physique (délais de positionnement de tête de disque, arrivées de paquets réseau, saisie clavier et souris, interruptions matérielles, RDRAND sur les processeurs Intel qui en disposent) au moyen d'une fonction de hachage cryptographique, puis se réamorcent en continu.

    Dans le navigateur, la Web Cryptography API du W3C l'expose via window.crypto.getRandomValues(typedArray) : donnez-lui un tableau typé, le navigateur le remplit d'octets aléatoires cryptographiquement robustes. Le maximum par appel est de 65 536 octets (cet outil reste bien en deçà). L'API bénéficie d'une prise en charge de base sur Chrome, Firefox, Safari et Edge depuis juillet 2015 : il n'existe aucune possibilité réaliste qu'un utilisateur arrive sur cet outil avec un navigateur qui en soit dépourvu.

    L'entropie des mots de passe, le calcul réel

    La « force » d'un mot de passe, au sens cryptographique formel, se mesure en bits d'entropie. La formule standard pour un mot de passe généré aléatoirement est :

    Entropie = L × log₂(R)

    où L est la longueur en caractères et R la taille du jeu de caractères. Entropie par caractère selon le jeu :

    Le nombre 94 mérite d'être précisé : les codes ASCII de 32 à 126 sont les caractères imprimables (95 au total) ; en retirant l'espace, il reste 94 glyphes visibles non blancs (26 minuscules + 26 majuscules + 10 chiffres + 32 signes de ponctuation/symboles). En injectant des nombres concrets dans la formule :

    La communauté cryptographique s'est accordée sur trois seuils : 80 bits comme strict minimum (le plancher recommandé par le NIST jusqu'en 2014), atteint à environ 13 caractères avec le jeu complet de 94 caractères ; 100 bits exigés par l'ANSSI (l'équivalent français de la NSA) pour les mots de passe protégeant les systèmes de chiffrement, atteint à environ 16 caractères ; et 128 bits correspondant à la robustesse de clé symétrique d'AES-128, recommandés pour les mots de passe maîtres de coffre-fort, atteint à environ 20 caractères.

    L'énorme réserve : ce calcul ne s'applique qu'aux mots de passe aléatoires. Si un humain a choisi le mot de passe, l'entropie effective est bien, bien plus faible. L'attaquant n'énumère pas les chaînes R^L par ordre alphabétique ; il exécute un programme de devinette amorcé avec des listes de mots de passe divulguées, des mots du dictionnaire, des substitutions courantes (a→@, o→0, s→$), des parcours de clavier et des modèles statistiques de la façon dont les humains construisent des chaînes mémorisables. L'étude de 2012 de Joseph Bonneau portant sur un corpus anonymisé de 70 millions de mots de passe Yahoo (IEEE Symposium on Security and Privacy) a constaté que les mots de passe choisis par les utilisateurs offrent « moins de 10 bits de sécurité contre une attaque de ratissage en ligne, et seulement environ 20 bits contre une attaque par dictionnaire hors ligne optimale ». Vingt bits, c'est un million d'essais. Un GPU moderne fait cela en microsecondes.

    NIST SP 800-63B, ce qui a changé en 2017 puis de nouveau en 2025

    Pendant une trentaine d'années, la politique de sécurité nord-américaine en matière de mots de passe a découlé d'une publication du NIST de 1985 qui recommandait une rotation périodique forcée, des classes de caractères mélangées et des longueurs minimales courtes. Bill Burr, auteur du document de suivi de 2003 qui a codifié la règle « majuscule + minuscule + chiffre + symbole, à changer tous les 90 jours », l'a publiquement reniée en 2017, déclarant au Wall Street Journal que « l'essentiel de ce que j'ai fait, je le regrette aujourd'hui ». Le NIST a formalisé ce revirement la même année.

    NIST SP 800-63B Rev 3 (juin 2017) a introduit deux changements générationnels. La section 5.1.1.2 indique : « Les vérificateurs NE DEVRAIENT PAS exiger que les secrets mémorisés soient changés arbitrairement (p. ex. périodiquement) », car les rotations forcées poussent les utilisateurs à choisir des mots de passe plus faibles et plus prévisibles. La même section : « Les vérificateurs NE DEVRAIENT PAS imposer d'autres règles de composition (p. ex. exiger des mélanges de différents types de caractères) pour les secrets mémorisés », car imposer un chiffre et un symbole pousse les utilisateurs vers Password1! plutôt que vers une phrase de passe plus longue. La Rev 3 a fixé la longueur minimale choisie par l'abonné à 8 caractères, exigé des vérificateurs qu'ils acceptent jusqu'à 64, imposé de vérifier les nouveaux mots de passe au regard de listes de blocage issues de fuites, et explicitement exigé que les gestionnaires de mots de passe et les collages depuis le presse-papiers soient autorisés.

    NIST SP 800-63B Rev 4 (finalisée le 31 juillet 2025) a relevé la barre : les mots de passe à facteur unique exigent désormais un minimum de 15 caractères (« Les vérificateurs et les CSP DOIVENT exiger que les mots de passe utilisés comme mécanisme d'authentification à facteur unique comptent au minimum 15 caractères »). Les mots de passe multifacteurs restent à 8 caractères, car le second facteur porte le poids de la sécurité. Les règles de composition demeurent interdites, et la formulation est passée du « NE DEVRAIENT PAS » de la Rev 3 au « NE DOIVENT PAS » de la Rev 4, en faisant une exigence ferme plutôt qu'une recommandation. La rotation reste déconseillée en l'absence de preuve de compromission.

    L'outil Absolutool utilise par défaut 16 caractères avec les quatre classes de caractères, ce qui donne environ 104 bits d'entropie et franchit confortablement à la fois le minimum de 15 caractères de la Rev 4 et le seuil d'équivalence symétrique de 80 bits. Le maximum de 128 caractères de l'outil représente exactement le double de la longueur maximale que le NIST impose aux vérificateurs d'accepter ; il n'existe aucun cas réaliste où un mot de passe généré serait trop long pour qu'un serveur l'accepte.

    RockYou, le désastre qui hante encore 2026

    En décembre 2009, l'entreprise de jeux sociaux RockYou a été compromise par une injection SQL d'école. La fuite a exposé plus de 32 millions de comptes utilisateurs, y compris les mots de passe de ces comptes en clair : RockYou les avait stockés sans chiffrement. La politique de mots de passe de l'entreprise à l'époque n'exigeait que cinq caractères et interdisait les caractères spéciaux, ce qui avait aggravé la vulnérabilité.

    Le fichier dérobé, vite surnommé rockyou.txt, a été publié ouvertement et demeure la liste de mots de passe la plus référencée au monde. Il est livré par défaut avec Kali Linux à l'intention des testeurs d'intrusion ; tous les outils d'attaque par dictionnaire de la planète le vérifient ; les services commerciaux de bourrage d'identifiants le maintiennent comme référence de base. Seize ans plus tard, les attaquants piègent encore des comptes actifs utilisant des mots de passe apparus pour la première fois dans la fuite de 2009. Les leçons qui se sont propagées : les serveurs ne devraient jamais voir de mots de passe en clair (cet outil génère côté client, de sorte que le serveur ne les voit pas du tout) ; les mots de passe stockés devraient être hachés avec une fonction lente, salée et exigeante en mémoire comme Argon2id ou bcrypt, et non avec un hachage rapide comme MD5 ou SHA-1 non salé ; des mots de passe uniques par site sont la seule défense contre l'attaque par rejeu d'identifiants volés qui a dominé la dernière décennie de fuites.

    Have I Been Pwned et le corpus de fuites

    Have I Been Pwned (HIBP), dirigé par le directeur régional Microsoft Troy Hunt, est devenu la source de référence faisant autorité pour la question : « ce mot de passe est-il apparu dans une fuite ? » Hunt a lancé HIBP en 2013 sous la forme d'un index consultable d'adresses e-mail compromises ; il y a plus tard ajouté le corpus Pwned Passwords, une liste téléchargeable de chaque mot de passe vu dans une fuite publique, indexée par empreinte SHA-1. Pwned Passwords V2 a été lancé le 22 février 2018 et a introduit l'API de k-anonymat du jeu de données (construite avec Cloudflare) : un client n'envoie que les cinq premiers caractères de l'empreinte SHA-1 ; le serveur renvoie toutes les empreintes complètes commençant par ces cinq caractères, accompagnées du nombre de fois où elles ont été observées ; le client compare localement. Le mot de passe (et même son empreinte complète) ne quitte jamais l'appareil de l'utilisateur.

    Pour un générateur en masse, l'intérêt est double. Tout mot de passe déjà présent dans HIBP n'est, par définition, pas un nouveau mot de passe utile ; ce sera la première chose qu'essaiera tout attaquant par bourrage d'identifiants. Et comme cet outil génère avec un aléa CSPRNG complet à partir d'un alphabet de 94 caractères, la probabilité qu'un mot de passe de 16 caractères fraîchement généré soit déjà dans HIBP est, en pratique, nulle. (Le nombre total de mots de passe de 16 caractères à symboles ASCII est de 94^16 ≈ 3,7 × 10³¹ ; HIBP contient environ 10⁹ mots de passe connus ; la probabilité de collision ≈ 10⁻²².)

    Ce que « X bits d'entropie » signifie en temps de cassage réel

    Le nombre qui donne un sens concret aux bits d'entropie est : « combien de temps faudrait-il à un attaquant moderne ? », et la réponse dépend entièrement de l'algorithme de hachage. Le banc d'essai publié par la communauté pour hashcat v6.2.6 sur une seule Nvidia RTX 4090 enregistre environ 300 GH/s pour les empreintes NTLM (l'ancien hachage Windows de Microsoft) et 200 kH/s pour bcrypt. L'écart de quatre ordres de grandeur entre les deux est le fait déterminant : NTLM a été conçu pour la vitesse, bcrypt a été conçu pour être lent.

    Les très citées tables de mots de passe de Hive Systems transforment ces bancs d'essai en durées de cassage. La version 2025 calculée pour des empreintes MD5 (presque aussi rapides que NTLM) donne environ 59 minutes sur une seule RTX 4090 pour casser par force brute un mot de passe de 8 caractères tiré du jeu complet. Le même mot de passe de 8 caractères, face à une empreinte bcrypt, prend environ 99 ans sur le même matériel. Cet écart de quatre ordres de grandeur, c'est la différence entre « fuité hier, cassé avant midi » et « fuité hier, vous survivra ».

    L'utilisateur final contrôle la longueur et le jeu de caractères du mot de passe. Il ne contrôle pas l'algorithme de hachage que le serveur utilise pour le stocker. La plupart des services modernes bien gérés utilisent bcrypt, scrypt ou Argon2id, tous délibérément lents. Les services plus anciens et les services compromis utilisaient fréquemment MD5 ou SHA-1 non salé, ce qui explique pourquoi les anciens corpus de fuites peuvent être cassés aux vitesses citées plus haut. Pour un mot de passe généré par cet outil : un mot de passe aléatoire de 16 caractères est à l'abri de bcrypt pour ainsi dire à jamais, et à peu près à l'abri de MD5 pour l'instant ; un mot de passe de 20 caractères est démesuré face à l'un comme à l'autre. Il n'existe aucun modèle de menace réaliste où plus de 20 caractères de sortie CSPRNG constitueraient le maillon faible.

    FIDO2, WebAuthn et la transition vers les clés d'accès

    La prédiction la plus ancienne du secteur de la sécurité est que les mots de passe vont disparaître. Depuis 2019, elle dispose enfin d'un remplaçant crédible : les clés d'accès (passkeys), le nom marketing grand public des identifiants délivrés selon les normes FIDO2 / WebAuthn. WebAuthn Level 1 est devenu une recommandation du W3C le 4 mars 2019 ; le Level 2 a suivi le 8 avril 2021. Le modèle cryptographique est asymétrique : lorsqu'un utilisateur s'enregistre, l'authentifieur génère une paire de clés publique/privée, envoie la clé publique au serveur et stocke la clé privée dans du matériel local sécurisé. L'authentification utilise un défi-réponse signé avec la clé privée. Le serveur ne voit jamais le secret, ce qui signifie qu'une compromission côté serveur ne peut pas exposer les identifiants de connexion.

    Les déploiements des grandes plateformes ont progressé de concert au fil de 2022-2023 : Apple a présenté les clés d'accès à la WWDC le 6 juin 2022 et les a livrées publiquement avec iOS 16, iPadOS 16 et macOS Ventura en septembre 2022, avec synchronisation via le trousseau iCloud chiffré de bout en bout. Google a annoncé la prise en charge des clés d'accès pour Android et Chrome le 12 octobre 2022 ; la prise en charge stable dans Chrome est arrivée avec Chrome 108 en décembre 2022, avec synchronisation via Google Password Manager. Microsoft a annoncé la gestion des clés d'accès pour Windows 11 le 21 septembre 2023, intégrée à Windows Hello.

    Les clés d'accès résolvent les catégories les plus douloureuses d'échec des mots de passe (hameçonnage, bourrage d'identifiants, compromission de serveur), mais elles n'ont pas éliminé les mots de passe parce que : de nombreux sites et la plupart des systèmes hérités en exigent encore un ; les clés d'accès sont liées à un appareil ou à un écosystème de synchronisation (les utilisateurs sans compte Apple, Google ou Microsoft ont besoin d'une solution de rechange) ; les systèmes sans interface (objets connectés, comptes de service côté serveur, scénarios d'enrôlement par lots) ne peuvent pas compter sur un authentifieur biométrique à l'étape d'enregistrement ; et de nombreuses politiques de mots de passe en entreprise, systèmes bancaires et portails gouvernementaux imposent encore des mots de passe. La génération de mots de passe en masse relève précisément des deuxième et troisième catégories : un administrateur système qui provisionne 50 nouveaux comptes ne peut pas demander à chaque futur utilisateur d'enrôler une clé d'accès avant que le compte existe.

    Pourquoi la génération côté client importe particulièrement

    Imaginez un outil concurrent qui envoie la requête de l'utilisateur en POST à un serveur, le serveur exécute le générateur aléatoire et renvoie la liste sous forme de JSON. Même si tout fonctionne comme annoncé, les parties suivantes peuvent voir les mots de passe générés en clair : la mémoire du processus serveur pendant le traitement de la requête ; les journaux de requêtes du serveur (si la journalisation est naïve) ; tout service d'APM ou de suivi d'erreurs auquel le serveur est raccordé ; le proxy inverse qui termine le TLS (Cloudflare, répartiteur de charge AWS, nginx) ; tout outil de débogage tournant sur le serveur ; tout attaquant futur qui obtient l'accès à l'un de ces journaux. Le modèle RockYou, avec toutes ses conséquences, s'applique.

    Lorsque la génération se fait via window.crypto.getRandomValues() dans le navigateur de l'utilisateur, rien de tout cela ne s'applique. Les octets sont produits à l'intérieur du processus du navigateur, sur la machine de l'utilisateur, par du code que l'utilisateur peut auditer (la source de la page est consultable). Ils ne traversent jamais le réseau. Le serveur d'Absolutool ne les voit jamais, ne les journalise jamais, et ne peut pas les divulguer lors d'une fuite future puisqu'il ne les a jamais eus. Les seules entités qui voient les mots de passe générés sont l'utilisateur, quiconque a accès à la session de navigateur de l'utilisateur (en général l'utilisateur seul), et les éventuelles extensions de navigateur actives sur la page. C'est le même modèle de sécurité que le générateur local d'un gestionnaire de mots de passe, et un modèle plus robuste que celui de tout service web qui renvoie des mots de passe générés depuis un serveur.

    Mirai 2016, le contre-exemple des identifiants par défaut de l'IoT

    Le contre-exemple d'école du « utilisons simplement le même mot de passe par défaut sur chaque unité » est le botnet Mirai. Mirai a exploité une liste codée en dur d'environ 62 combinaisons identifiant/mot de passe par défaut des fabricants (admin/admin, root/root, root/xc3511, root/vizxv) pour infecter des centaines de milliers de caméras IP, d'enregistreurs vidéo et de routeurs domestiques fin 2016, puis s'en est servi le 21 octobre 2016 pour mettre hors service le grand fournisseur DNS Dyn, coupant brièvement Twitter, Reddit, Netflix et GitHub. Un générateur de mots de passe en masse est précisément la bonne primitive pour l'alternative : produire un mot de passe par défaut unique et robuste par unité sur la chaîne de production, l'imprimer sur une étiquette, le livrer dans la boîte.

    Plus de questions

    Pourquoi le NIST recommande-t-il la longueur plutôt que la complexité ?

    Parce qu'imposer de la complexité (un chiffre, un symbole, une lettre majuscule) pousse les utilisateurs dans des schémas prévisibles que l'attaquant a déjà modélisés. Password1! a mathématiquement plus d'entropie que password, mais en pratique la liste de mots de chaque attaquant commence là. Une chaîne de 20 caractères tout en minuscules issue d'un CSPRNG a environ 94 bits d'entropie et ne peut être devinée par aucune liste de mots, parce qu'elle ne correspond à aucune liste de mots. La NIST SP 800-63B Rev 4 (juillet 2025) érige l'interdiction des règles de composition en exigence ferme et impérative, et non en simple recommandation.

    Devrais-je plutôt utiliser des phrases de passe ?

    Pour les mots de passe que vous devez mémoriser, oui : c'est ce que défendait le xkcd #936 (10 août 2011). La méthode Diceware (Arnold Reinhold, 1995) donne 12,9 bits par mot à partir d'une liste de 7 776 mots ; six mots ≈ 77,5 bits est la recommandation moderne. L'EFF a publié des listes de mots à jour, compatibles avec Diceware, en juillet 2016. Mais pour le cas d'usage de provisionnement en masse que sert cet outil (jetons temporaires changés à la première connexion), l'ASCII aléatoire est la bonne primitive, car l'utilisateur n'a jamais besoin de le taper.

    Exclure les caractères ambigus est-il un compromis de sécurité ?

    Oui, techniquement, retirer i, l, 1, L, O, 0, o réduit l'alphabet de 94 à 87, abaissant l'entropie par caractère de 6,55 bits à 6,44 bits. À 16 caractères, cela fait 103,0 bits au lieu de 104,8 bits, ce qui est totalement négligeable. Le compromis est payant lorsque des humains doivent lire le mot de passe à voix haute ou le recopier depuis une feuille imprimée, ce qui est exactement le scénario de distribution en masse que sert cet outil.

    Quelle est la façon la plus sûre de distribuer une liste générée ?

    Traitez la liste générée comme un artefact à usage unique. Distribuez-la par un canal convenu à l'avance (courriel chiffré avec PGP/GPG, transfert de fichiers sécurisé, import dans un gestionnaire de mots de passe, remise en main propre pour les contextes à enjeux élevés). Configurez les systèmes pour exiger un changement de mot de passe à la première connexion. Supprimez le fichier après distribution. N'envoyez jamais de listes en clair par courriel, ne les validez jamais dans un système de gestion de versions, ne les collez jamais dans une messagerie. Les mots de passe générés sont conçus comme des jetons à usage unique : la valeur réside dans l'aléa cryptographique pour la remise initiale, non dans une conservation à long terme.

    Outils associés

    Générateur de mot de passe

    Créez un mot de passe aléatoire robuste.

    Encodeur Base64

    Encodez et décodez du Base64 instantanément.

    Générateur de chaînes aléatoires

    Générez des chaînes aléatoires avec des motifs personnalisés.