Un mot de passe pour les gouverner tous ?

L’application FantomApp embarque un vérificateur de mot de passe. Cette fonctionnalité peut être déstabilisante pour qui ne comprend pas comment sont calculés les résultats proposés. Revenons pour cela sur les mots de passe, leur conception, leur stockage et les calculs du vérificateur.

 

« Oui, c’est bien moi, FantomApp »

 

Le 16 décembre 2025 sortait l’application FantomApp, développée par la CNIL dans le cadre d’un projet financé par l’Union Européenne. FantomApp a pour objectif d’outiller et d’aider les collégiens. Comme expliqué dans les articles couvrant les enquêtes réalisées auprès des jeunes, les adolescents ont déjà assimilé des pratiques de cybersécurité concernant leur activité en ligne. Que cela passe par la méfiance vis-à-vis de certains réseaux sociaux, la publication de « stories » temporaires plutôt que de photos qui resteraient ad vitam aeternam, ou encore la conscience des conséquences liées à une forte exposition en ligne, les exemples de stratégies mobilisées par des collégiens ne manquent pas.

L’application FantomApp ne vise pas à dicter des règles strictes, pas forcément adaptées à un public collégien, mais au contraire à les accompagner en les outillant de manière responsable en matière de cybersécurité.

Pour cela, FantomApp met à disposition différents modules :

• « J’ai un problème » : un espace dédié aux ressources mobilisables lors de situations potentiellement problématiques en ligne, qu’il s’agisse de l’effacement de contenu, du piratage jusqu’au chantage sexuel – les différents onglets permettent en un clic d’accéder à l’aide nécessaire.
• « Outils » : cette rubrique met à disposition trois outils permettant de vérifier et d’améliorer sa sécurité en ligne, à savoir, un testeur de mot de passe (voir plus bas), un outil de floutage de photo, et un questionnaire sur les informations personnelles présentes dans les pseudos/biographies des profils sur les réseaux. Tous fonctionnent en local, aucune donnée n’étant remontée aux serveurs. Les utilisateurs peuvent donc tester leurs mots de passe et flouter leurs photos en toute confidentialité.
• « Me sécuriser » : ce module liste certains des réseaux sociaux les plus utilisés et guide les utilisateurs à travers leurs paramètres à l’aide de captures d’écrans, afin d’améliorer leur confidentialité en ligne. Des check-lists sont proposées en fonction des options disponibles (localisation, sécurité, visibilité, bon réflexe).

 

« Le mot de passe idéal, c’est simple : il a tous les défauts. »

 

Avoir un bon mot de passe est essentiel, mais qu’est-ce que cela implique ? Souvent, il est recommandé de suivre des contraintes telles que :

• 1 chiffre ;
• 1 majuscule ;
• 1 caractère spécial ;
• Au moins 8, ou 10, ou 12 caractères (la CNIL en recommande douze).

La plupart des sites ou des réseaux sociaux sur lesquels nous créons des comptes nous forcent à rentrer dans ces clous, ce qui donne parfois une fausse impression de sécurité, sans aller plus loin sur la bonne combinaison de ces facteurs. Comme le rappelle l’article « De ‘azerty’ à ‘pa$$word’ une revue des pratiques de gestion des mots de passe », le mot de passe « Motdepasse123! » qui respecte pourtant les critères énoncés ci-dessus n’est pas si sûr que cela. Il en est de même pour le très connu « Pa$$w0rd », en tête des listes des mots de passe à ne pas utiliser.

 

https://xkcd.com/936/

Pour déterminer la robustesse d’un mot de passe, il est possible d’utiliser la notion d’entropie adaptée au cas d’espèce. Dans ce contexte, il s’agit d’une mesure objective et facile à calculer qui correspond à l’ensemble des possibilités que peut prendre votre mot de passe. Elle sert de limite haute au calcul du temps estimé pour « casser » votre mot de passe.

 

 

Attention, cette mesure d’entropie est imparfaite car elle repose sur l’hypothèse (souvent fausse pour un humain) que vous choisissez votre mot de passe de manière totalement aléatoire. C’est comme si chaque mot de passe possible (une suite de 12 caractères parmi ceux autorisés) était inscrit sur un petit papier dans un grand chapeau, et que vous tiriez un papier au hasard pour choisir votre mot de passe. Or, il est difficile pour nous, simples mortels, de choisir des mots de passe « vraiment » au hasard parmi tous ceux qui sont possibles. Nous sommes biaisés avec une tendance à choisir des mots de passe qui ont un sens pour nous, et qui sont plus faciles à retenir.

 

 

Voyez ici la fréquence de choix des codes PIN. Il pourrait être facile de considérer que la sécurité d’un code PIN repose sur la taille de l’ensemble des possibles. Ici l’espace est de 10 chiffres pour 4 numéros, donc 10⁴ = 10000, or nous voyons bien dans cette répartition que la plupart des codes PIN se trouve dans un rectangle en bas à gauche, où les deux premiers chiffres représentent un mois, et les deux suivants le jour de ce mois-là, vous l’aurez deviné des dates de naissance. Pareil pour la grande verticale au-dessus des nombres commençant par 19 pour les gens nés au XXème siècle. Ou encore la diagonale des doublons. Bref, généralement l’entropie d’un code PIN est moins élevée que ce que l’on voudrait penser.

 

De même en calculant l’entropie d’un mot de passe tel que : « Motdepasse123 ! ». En théorie, ce mot de passe de longueur 14 a une grande entropie (supérieure à 75, faites le calcul avec la formule ci-dessus). Mais si vous avez vraiment choisi un mot de passe au hasard parmi ceux de 14 caractères, vous avez autant de chance de choisir « Motdepasse123! » que « xB#3Tt!bYak$c2 ». Bizarrement, les humains ont plutôt tendance à faire le premier choix.

Donc parler d’entropie sans vrai aléa, c’est un peu un abus de langage, que nous allons tout de même faire dans cet article.

 

Trouver un bon mot de passe

 

Nous voyons donc que trouver un bon mot de passe ne se résume pas à obtenir une entropie élevée. Il y a d’autres règles, comme, par exemple, ne pas utiliser son nom, son prénom, celui de ses enfants ou de ses animaux de compagnie.

Les « vrais » hackeurs utilisent en effet des listes de mots de passe pré-faites, qui leur permettent d’essayer un large nombre de combinaisons différentes, à partir de mots connus en fonction de la langue des utilisateurs. Ces listes peuvent même contenir des combinaisons de plusieurs mots, ou des assemblages avec des chiffres, des remplacements des « a » par des « @ », etc. Il ne suffit donc pas d’écrire « Motdep@sse123! » pour être à l’abri.

De plus, ils réutilisent (les gredins) des listes de mots de passe issues de fuites de données, parmi lesquelles se trouve peut-être les données d’un jeu en ligne auquel vous avez arrêté de vous connecter depuis longtemps mais… Oups, vous utilisez le même pour votre réseau social préféré ? C’est pourquoi la CNIL vous recommande aussi de ne pas utiliser le même mot de passe pour plusieurs sites.

Pour plus d’informations sur comment créer un bon mot de passe, le site de la CNIL vous propose un générateur de « passe-phrase », des mots de passe que l’on retient facilement et qui paraissent pourtant très compliqués, tout en respectant les critères imposés par les sites.

Une fois votre passe-phrase créée, vous pouvez la tester dans le vérificateur de FantomApp. Si vous n’obtenez pas un « super » n’hésitez pas à nous le signaler !

 

Le temps est long, la pastille est bleue

 

Dans FantomApp, nous avons pris le parti d’ajouter une case lors de la création d’un mot de passe : « contient mon prénom, nom, ou des mots faciles à deviner ». Tout en gardant un calcul d’entropie classique, cette case permet de montrer tous les cas où un hackeur devine votre mot de passe, ou a utilisé une liste de mots de passe toute faite. Le temps obtenu est alors toujours « instantané ».

 

Un problème dans l’appli ?

Ainsi, plusieurs remarques ont été faites sur certains résultats, notamment pour notre exemple favori, où le temps affiché pour « Motdepasse123! » (si vous ne cochez pas la case) est de 19 billions d’années (soit 19 mille milliards)

Comme vu dans l’exemple, le nombre de bits d’entropie (théorique, car cette notion ne marche qu’avec un choix aléatoire de caractères) de ce mot de passe est supérieur à 75. Mais dans la réalité si votre sécurité repose sur « Motdepasse123! », inutile de calculer un temps, vous êtes déjà compromis par le choix des mots et chiffres que vous avez effectués.

Pour transformer ces bits d’entropie en temps nous utilisons la matrice calculée par Hive System, une entreprise spécialisée dans la cybersécurité qui chaque année estime le temps qu’il faut pour retrouver un mot de passe en fonction du nombre de ses caractères et de sa composition (majuscules, nombre, caractères spéciaux, etc.). Vous pouvez retrouver celle utilisée pour FantomApp sur leur site. 

Vous pouvez donc vérifier par vous-même : un mot de passe composé de 14 caractères et comprenant majuscules, minuscules, nombres et caractères spéciaux : « 19 tn years » sur la matrice, traduction : « 19 billions d’années ».

Cette matrice, republiée sur le site de FranceNum, est utilisée par de nombreux experts du monde de la cybersécurité comme une référence pour estimer la robustesse d’un mot de passe.

Il y a bien sûr des limitations à cette estimation, et HiveSystem les décrit sur son site web :

1. Ils assument que votre mot de passe n’a pas fait partie d’une fuite de données qui permettrait de le retrouver en clair ;
2. Ils assument que votre mot de passe est généré aléatoirement, dans le sens où il ne peut pas être deviné par un hackeur et que celui-ci doit tester toutes les combinaisons. Une sorte de « pire scénario » possible, donnant une limite supérieure au temps qu’un attaquant mettrait à trouver votre mot de passe ;
3. Enfin, ils utilisent un clavier en QWERTY, sans les accents que nous en utilisons en français. Cette dernière contrainte réduit la taille possible de l’entropie de votre mot de passe.
4. D’autres limitations sont mentionnées sur leur site.  

Il faut noter par ailleurs que cette table repose sur l’algorithme de hachage « bcrypt » avec un degré de travail mis à 10. Le prochain paragraphe vous éclairera sur ce que cela signifie.

 

« Hachez, salez, poivrez : la petite cuisine de la sécurité informatique »

 

Ce titre, que nous avons emprunté à ce billet de blog, introduit trois notions intéressantes dans la gestion des mots de passe. Parlons de hachage.

Le hachage (hash en anglais) est une technique cryptographique permettant, entre autres, de stocker des mots de passe dans une base de données, sans écrire le mot de passe tel quel. En effet, les fonctions de hachage sont des fonctions mathématiques complexes qui transforment une chaîne de caractère quelconque (un texte, un programme, un mot de passe, etc.) en une suite de caractères de longueur fixe, unique, de manière déterministe et non réversible. C’est-à-dire que pour une même entrée, la fonction donnera toujours la même réponse, et pour une entrée différente la fonction donnera une réponse différente. L’intérêt d’une fonction de hachage (si elle est bien faite) est qu’elle est irréversible : à partir du hash d’un message, vous ne pouvez pas remonter au texte original. De plus, bien que déterministes, elles ont aussi l’avantage de donner des résultats très différents, même pour deux entrées très similaires.

Par exemple un hash de « Motdepasse123! » est :

f77ec526c574835c048c417ca3786c350f08781d83217d0478b96f85ffb8fac4

Et celui de « Motdepasse123? » est :

74f4f4c50da00a13d3f7061be46d973a69f7c897e2478745e1111b32f33db80f

Rien à voir si ce n’est que ça ressemble à du charabia.

Il existe différentes méthodes de hachage, avec différentes utilités pour chacune d’entre elles. Dans l’exemple présenté ici, la fonction de hachage est « SHA256 », mais il en existe de nombreuses autres, comme « bcrypt » mentionnée plus tôt.

 

Pourquoi on en parle ?

Quand un hackeur essaye de trouver votre mot de passe, en général, il n’essaie pas de se connecter à votre compte Facebook ou Instagram en testant une série de mots de passe à la suite. Il aura trois essais avant de se faire bloquer du site et vous recevrez une alerte. C’est pourquoi les hackeurs essaient de retrouver vos mots de passe dans des bases de données qui ont fuitée, c’est beaucoup plus simple.

La base de données est en générale constituée de :

1. votre adresse mail ;
2. le hash de votre mot de passe ;
3. le sel de votre mot de passe (nous verrons plus tard ce que ça veut dire).

Si les mots de passe n’étaient pas hachés, la matrice de HiveSystem n’aurait aucun intérêt car tout serait en « instantané » puisqu’il suffirait au hackeur de lire la base.  

Il est donc important de comprendre les mécanismes derrière le stockage des mots de passe et pourquoi les hackeurs mettraient du temps à les casser.

Dans de nombreux cas les mots de passe sont donc stockés sous forme de hash dans les bases de données (il existe encore des sites qui n’utilisent pas de fonctions de hachage, mais c’est de plus en plus rare). Une base de données qui a fuité ne comporte pas vos mots de passe « en clair », donc sous forme lisible, mais vos mots de passe hachés, qui ressemblent à du charabia. Quand vous vous connectez à un site, votre mot de passe est d’abord haché, puis on le compare au hash stocké dans la base de données. Evidemment, si vous essayez de mettre le hash de votre mot de passe à la place de votre mot de passe pour vous connecter à un site, votre mot de passe se fera rejeter.

Mais cette mesure de sécurité n’est pas sans failles. En effet, n’importe qui peut utiliser une fonction de hachage. Il existe donc des tables de correspondances entre les mots de passe les plus utilisés et leurs hash correspondants. C’est ce qu’on appelle les Rainbow Tables. Les hackeurs les utilisent sur les listes de mots de passe connus, et peuvent ensuite comparer les hash obtenus avec ceux d’une base de données qui a fuitée. Ce qui leur permet d’aller très vite en termes de cassage de mot de passe.

 

Et un peu de sucre sel en poudre

Pour se protéger des attaques par tables de correspondance (Rainbow Tables), il existe deux concepts repris dans le titre de cette section : le sel et le poivre. Ces noms sympathiques sont là pour exprimer le fait qu’une fois rajouté au hash de votre mot de passe, il n’est plus possible les enlever. Comme lorsque vous faites tomber le pot de sel dans la soupe, c’est trop tard. 

Pour faire simple, un « sel » est une chaîne de caractères aléatoires qui est rajoutée au mot de passe avant de le hacher, et qui est stockée à côté de celui-ci dans la base de données. Ainsi quand un utilisateur se connecte à un site, ce sel est ajouté à son mot de passe, et vous vérifiez qu’il correspond bien à celui que vous aviez enregistré.

Votre table ressemble donc à ça :

identifiant | hache(mot de passe + sel) | sel (wiki)

Donc par exemple :                                                                                                                                                                                                  

User1  | 7122b098b28aa1e1c944e3565a69a6c84d46a6c573f06938a19be0e5d915a923 | kOb#0o7mA(VbSruP

Le hash représenté ici est le résultat de la fonction de hachage SHA256 du mot de passe « Motdepasse123? » et du sel « kOb#0o7mA(VbSruP ».

Cela apporte différents avantages :

1. Deux mots de passe identiques ont des hash différents ;
2. Les tables de correspondance (Rainbow Tables) ne fonctionnent plus, étant donné qu’il s’agit de hash précalculés sur des mots de passe connus et sans sel ;
3. Un attaquant ne peut plus tester tous les hash de la base en même temps, il doit à chaque fois rajouter le sel spécifique à un utilisateur.

C’est cette troisième propriété qui nous intéresse.

Sans le sel, quand un attaquant récupérait une base de données simplement hachée, il pouvait soit utiliser des tables de correspondance et comparer les bases, soit tester tous les mots de passe en les hachant à chaque fois, et comparer avec la base. Ce qui donnerait :

Hash(« a ») = hash_de_a, est-ce que hash_de_a est dans la base ?

Hash(« b ») = hash_de_b, est-ce que hash_de_b est dans la base ?

Hash(« ab ») = hash_de_ab, est-ce que hash_de_ab est dans la base ?

Etc. Un processus long, mais qui permet à chaque fois de comparer avec toute la base. Hackeur vaillant, rien d’impossible.

Le sel empêche cette comparaison, l’attaquant doit maintenant choisir un sel en particulier à attaquer, et hacher toutes les combinaisons possibles de mot de passe avec ce sel, pour à la fin casser un seul mot de passe de la base. Ainsi si un hackeur arrivait quand même à générer votre mot de passe en essayant d’en attaquer un autre, il ne le saurait pas. Et c’est pourquoi le temps estimé est si long dans les tables proposées par HiveSystem. Tout ça pour ça. Mais l’important ce n’est pas la destination, c’est le voyage.

 

Le hash ça prend son temps

Une fonction de hachage de mot de passe est dite robuste pour plusieurs raisons, l’une d’entre elles est son temps d’exécution. Il ne doit pas être trop long : attendre deux minutes avant de pouvoir se connecter n’est pas acceptable, mais s’il est trop court, hacher un grand nombre de mots de passe devient trop facile.

Dans la table de HiveSystem, le parti est pris d’utiliser une fonction de hachage courante (la plus présente dans les différentes bases de données ayant fuité ces dernières années), avec un facteur de « travail » adapté à ce qui est le plus fréquemment mis en place. Ce facteur de travail est une représentation du temps qu’il faut pour réaliser un hash, un facteur trop petit et un hackeur pourrait reproduire le hash trop rapidement, un facteur trop grand et vous mettrez trop longtemps à hacher les mots de passe de vos clients, leur donnant l’impression d’un temps de latence trop important.

Nous sommes donc sur une fonction de hachage appelée « bcrypt » et dont le facteur de travail est de « 10 ». Cette valeur est un minimum utilisé dans différentes librairies.

 

Et le poivre ?

Concrètement il s’agit d’une sorte de sel secret, soit une chaîne de caractère qui est rajoutée à tous les mots de passe de la base de données avant d’être hachés, mais qui n’est pas stockée dans la base. L’entreprise va garder ce poivre bien caché dans ses serveurs, rendant impossible les attaques par force brute, si le hackeur n’a pas au préalable infiltré son réseau.

Chez la plupart des grands acteurs (Google, Meta, etc.) bien que ça ne soit pas mentionné explicitement, ou même pas mentionné sous la forme de « poivre », il existe une forme de sécurité similaire.

Cette sécurité est inutile si vous utilisez le même mot de passe partout, y compris sur des services moins sécurisés, qui n’ont pas de poivre, ou pire, pas de sel. Un mot de passe qui a fuité une fois va évidemment être réutilisé par les hackeurs, et comme cela est mentionné dans la publication de HiveSystem, si votre mot de passe a fuité la table de cassage devient :

 

 

Pour en savoir davantage sur le sujet du poivre n’hésitez pas à aller consulter le billet de blog mentionné plus haut.

 

Pourquoi ne pas embarquer une base de mots de passe dans l’appli ?

 

Certains testeurs de mot de passe en ligne proposent de regarder dans les bases de données qui ont fuité pour voir si votre mot de passe y apparaît, ou s’il est proche d’un mot de passe présent dans une base. C’est une fonctionnalité utile mais qui malheureusement s’appuie sur des données qui ont été communiquées suite à des fuites.

En plus des difficultés techniques que pose l’intégration, et le maintien à jour, d’une telle base dans une application embarquée, cela soulèverait également des questions juridiques puisque utiliser ces bases pourrait s’apparenter à du recel de données.

 

En conclusion

 

L’application FantomApp vous permet de vérifier si l’entropie de votre mot de passe est bonne, et d’obtenir un score ludique sur le temps qu’il faudrait à un hackeur naïf pour le trouver. Ce temps est basé sur le fait que votre mot de passe est censé être proche d’une chaîne de caractères aléatoires, donc qu’un hackeur ne pourrait pas le trouver en le devinant. Evidemment le calculateur renverra la même valeur de temps pour « Motdepasse123! » et « xB#3Tt!bYak$c2 », qui remplissent les même condition (longueur, majuscule, minuscule, chiffres et caractères spéciaux). Attention donc à l’interprétation du temps affiché, il n’est valable que pour des mots de passes ressemblants à la deuxième chaîne de caractère.

Ce vérificateur est en local sur votre téléphone ou votre navigateur, et aucune donnée n’en sont exfiltrées. Vous pouvez donc tester vos mots de passe en toute tranquillité, tout en vous informant sur les bonnes pratiques de création d’un mot de passe.

Si nous ne mentionnons pas les gestionnaires de mots de passe, cela a à voir avec la cible de notre application. Bien qu’essentiels à une bonne hygiène numérique, les gestionnaires de mots de passe peuvent paraître compliqués pour des enfants de 10 à 15 ans, et choisir un mot de passe fort est déjà une première étape. Nous incitons par ailleurs les utilisateurs à activer la double authentification (voir les conseils dans la rubrique « Me sécuriser »).

Si vous voulez tout de même en savoir plus sur ces gestionnaires, vous pouvez consulter l’article de Wired qui fait le point sur les gestionnaires de mots de passe intégrés dans les navigateurs. Ces gestionnaires simples d’utilisation et très répandus n’ont pas que des qualités. Un premier réflexe est d’ailleurs d’activer la sécurisation de l’accès à votre base de mot de passe enregistrée dans le navigateur. Sinon, quand vous laissez votre ordinateur déverrouillé, n’importe qui peut venir lire tous vos secrets.

Enfin, rappelons ici une ressource pour générer un mot de passe solide, le générateur de mot de passe de la CNIL peut vous aider à trouver des pistes de bons mots de passe.

Vous trouverez plus de ressources sur comment créer un bon mot de passe en téléchargeant le PDF suivant. Ce sont les fiches et outils pédagogiques que nous avons utilisé lors d’ateliers dans des collège d’Île de France pour comprendre les besoins des jeunes en matière de sécurité.

 

Illustration : LINC