Les indicateurs de force de mot de passe sont-ils trompeurs ?
17 septembre 2021 / Par Paul
Temps de lecture : 9 min
17 septembre 2021 / Par Paul
Temps de lecture : 9 min
Vous avez très certainement déjà croisé un indicateur de force de mot de passe sur internet ? Mais si… Cette fameuse jauge qui passe du rouge au vert lorsque votre mot de passe est suffisamment sécurisé ou non ? Par exemple ici sur le site Mon Compte SNCF.
Mais bien souvent vous verrez cet indicateur avec une liste de règles de sécurité de mot de passe, totalement arbitraires, à respecter, comme ci-dessous.
Sur ces deux derniers exemples, tout est vert. Nous pourrions croire que le mot de passe est sécurisé ! Malheureusement pas tout à fait et ceci pour deux raisons que nous allons tâcher d’explorer ensemble.
Il existe plusieurs outils appelés estimateurs (Exemple : experte.com ; Vpnmentor.com ; security.org). Ces estimateurs permettent de représenter la vitesse que mettrait l’ordinateur d’un “pirate” équipé de bons logiciels pour deviner notre mot de passe par attaque par dictionnaire (dictionnary attack) et attaque par force brute (brute force attack).
Prenons le mauvais mot de passe par excellence : « password ».
Le premier calculateur nous indique qu’il pourrait être deviné par un ordinateur en 5 secondes, et le deuxième estimateur en quelques minutes.
Appliquons maintenant à ce mauvais mot de passe une technique avant-gardiste [qu’aucun pirate informatique ne connait bien évidemment], et transformons-le en « P@ssw0rd!123 » (avec un zéro). Cela semble bien mieux maintenant. Tentons à nouveau…
Le premier calculateur nous indique qu’il pourrait être deviné par un ordinateur en 34 mille ans, et le 2ème en une éternité. Nous ne savons pas exactement combien de temps représente «une éternité» mais cela paraît suffisamment long !
Le souci avec ces indicateurs de force de mot de passe classiques c’est qu’ils reposent sur des calculs mathématiques simples. Ils partent du principe que plus nous mettons de caractères « complexes », plus le mot de passe est fort. Or, le cerveau humain ne sait pas construire de mots de passe à la fois complexes, totalement uniques, et faciles à retenir. Nous allons naturellement faire appel à des biais cognitifs et des modèles de construction classiques : des mots courants, des noms, des remplacements de lettres par des caractères similaires, des majuscules en début de mots, des répétitions, des séquences, etc…, et bien évidemment, les pirates prennent donc en compte ces faiblesses humaines dans leurs outils, ce qui rend caduque toute tentative de mesurer la force d’un mot de passe de cette manière. Intel nous fournit un très bel exemple de mot de passe clairement généré par un cerveau humain, et utilisant le même estimateur de force imparfait utilisé précédemment : voir ci-dessous.
Une image extrêmement connue dans le monde de la sécurité l’explique très bien :
Pour résumer, l’image explique qu’un mot de passe classique créé de toute pièce par un cerveau humain avec ses biais et modèles, avec majuscules, minuscules, chiffres et caractères spéciaux est beaucoup plus simple à deviner par un ordinateur et beaucoup plus difficile à retenir par un humain qu’une phrase secrète (passphrase) composée de mots ordinaires et minuscules.
Toutes les règles de sécurité de mot de passe qui ont été mises en place par les sites web ces 20 dernières années, nous ont habitué à créer et à utiliser des mots de passe qui sont difficiles à retenir mais faciles à deviner pour un ordinateur !
Heureusement il y a une solution à ce problème : zxcvbn.
Zxcvbn est une librairie CoffeeScript open-source développée par Daniel Lowe Wheeler qui l’a présenté lorsqu’il travaillait chez Dropbox. L’explication technique est détaillée ici.
Zxcvbn est un indicateur de force de mot de passe à implémenter dans un formulaire de création/changement de mot de passe. Il s’inspire des outils qu’utilisent les pirates informatiques pour deviner des mots de passe complexes et en grand nombre.
La librairie reconnaît les 30k mots de passe les plus courants, les prénoms et noms courants, les mots anglais les plus populaires d’après une liste de Wikipedia, des séries TV et films, et différents modèles de construction comme les dates, les codes postaux, les répétitions (aaa, 111), les séquences (abcd, 1234), les modèles de claviers types (azerty, qwerty), et le langage l33t (p@ssw0rd), ou n’importe quelle combinaison. Elle peut également prendre en compte une liste personnalisée de mots pour par exemple éviter que l’utilisateur utilise son nom, prénom ou email dans son mot de passe, mais également des mots spécifiques au contexte du site sur lequel il est présent (le nom du site, du vocabulaire spécifique).
Elle retourne un score de force entre 0 et 4 et des suggestions pour l’améliorer. Typiquement, elle est conçue pour considérer le mot de passe «P@ssword!123» comme médiocre et la passphrase «correcthorsebatterystaple» comme très forte.
Un exemple :
La librairie n’est plus maintenue depuis 2017 mais de nombreux projets latéraux ont émergé pour la développer dans d’autres langages et plateformes (iOS & Android également), notamment zxcvbn-ts en TypeScript. Cette dernière ajoute une gestion multilingue et beaucoup d’autres listes et dictionnaires à jour et spécifiques à la langue.
Basé sur les recommandations d’acteurs de la sécurité, nous vous conseillons également de retirer toutes les règles de « sécurité » de mot de passe rendues caduques par cette librairie.
C’est donc grâce à un indicateur de force de mot de passe efficace, que les mots de passe de vos utilisateurs seront plus résistants aux attaques par dictionnaire et par force brute !
Le deuxième souci est dû à un problème bien plus important. Dû à l’augmentation des règles de « sécurité » arbitraires et à la difficulté de créer des mots de passe complexes et uniques de tête, les utilisateurs finissent par avoir des mots de passe relativement simples et à les réutiliser (soyons honnêtes, qui ne l’a pas fait ? Nous avons tous des cadavres dans notre placard !) accouplés à leur adresse email unique bien évidemment. Malheureusement, les brèches de données se sont vraiment très fortement accélérées ces 6 dernières années, et nous trouvons des quantités faramineuses de couples email/hash de mots de passe disponibles publiquement.
Pour un pirate, avoir accès à la base de mots de passe hachés directement sur leur PC est un bonheur car cela permet à leurs logiciels de travailler beaucoup plus vite pour deviner les mots de passe. Vu que certaines bases de données ont parfois des mauvaises pratiques de sécurité de conservation des mots de passe (un hash SHA1 sans sel par exemple), et que ces derniers sont relativement faciles à deviner, tout cela ne fait qu’accélérer encore le processus. Les pirates se retrouvent très rapidement avec des listes gigantesques de couples email/mot de passe en clair. Et c’est maintenant que commencent les dégâts…
Les pirates utilisent la technique du bourrage d’identifiants (Credential Stuffing) pour réutiliser ces identifiants sur d’autres sites web connus, et comme dans de nombreux cas, les utilisateurs réutilisent leurs mots de passe, les pirates arrivent à accéder aux comptes.
Et dans les cas où ils n’arrivent pas à accéder aux comptes car les mots de passe ont déjà été changés, il faut savoir qu’il y a maintenant au minimum 613 millions de mots de passe uniques qui se baladent (ou se baladaient) en clair sur le web, donc compromis. Autant dire, qu’ils auront toujours une très belle liste des mots de passe les plus courants. Heureusement, il y a également une solution à ce problème : PwnedPasswords.
PwnedPasswords est un service qui permet à un utilisateur de vérifier la présence d’un de ses mots de passe dans des listes publiques de mots de passe compromis provenant de brèches de données.
Il est mis à disposition gratuitement par le chercheur en sécurité et MVP Microsoft Troy Hunt, qui fait également partie des conseillers du gestionnaire de mot de passe 1Password et conseiller stratégique de l’entreprise NordVPN.
PwnedPasswords repose sur des Azure Functions, un cache CloudFlare, et un principe de k-anonymité sur l’API pour que le mot de passe ne soit jamais dévoilé au serveur lors de la vérification. Le service a été récemment rendu open-source et intégré dans la .NET Foundation. Il est alimenté par les brèches de données publiques régulièrement dévoilées mais également par les données récupérées par le FBI. Utilisés par près de 30 gouvernements, le navigateur Firefox, les gestionnaires de mot de passe 1Password, Bitwarden, NordPass, Github, ont servi d’inspiration pour les alertes de mots de passe de Google Chrome et de Microsoft Edge, et intégrés nativement dans le Framework PHP Laravel.
De ce fait, on peut dire qu’entre les références de Troy Hunt et celles de PwnedPasswords, nous pouvons dormir sur nos deux oreilles : c’est un service fiable !
Regardons tout de suite ce qu’il en retourne avec nos deux mauvais mots de passe :
Ces mots de passe ont déjà été utilisés et compromis dans une brèche un bon nombre de fois. Comme vous vous en doutez, il faut faire en sorte de ne plus utiliser les mots de passe qui ont déjà été compromis auparavant, qu’ils aient été compromis dans un couple d’identifiant dont l’email vous appartenait ou dans celui de quelqu’un d’autre. Etant la technique la plus efficace, ce sera la toute première chose que les pirates testeront: d’abord le bourrage d’identifiants, en second temps une attaque par dictionnaire, et éventuellement une attaque par force brute.
Concernant l’implémentation, la base de données de mots de passe compromis est téléchargeable également si besoin d’éviter d’utiliser l’API k-anonymité.
Cela permettra aux mots de passe de nos utilisateurs de pouvoir résister aux attaques par bourrage d’identifiants.
Bon voilà, nous avons vu les deux protections à mettre en place. Nous vous proposons de vous montrer un exemple d’implémentation possible sur le vérificateur de force en ligne de NordPass, qui implémente nos deux solutions précédentes, mais à vous de choisir où vous l’implémenterai (connexion, inscription, renouvellement de mot de passe, bloquant ou non bloquant) :
En bleu vous voyez l’implémentation de la librairie zxcvbn et en rouge celle de l’API PwnedPasswords. On remarque que zxcvbn prend parfaitement en compte la correcte force de « correcthorsebatterystaple » et que les règles de sécurité sont ici gênantes pour autoriser ce genre de mot de passe. De plus, l’ordre de grandeur du temps nécessaire pour le deviner est bien plus raisonnable et cohérent. On voit cela dit que le mot de passe a été compromis dans 130 brèches, mais rien d’étonnant à cela vu qu’il a été exposé publiquement dans une image très connue sur internet.
Et concernant « P@ssw0rd!123 » ?
Nous voyons de nouveau que les règles ne servent à rien ! Même en respectant toutes les règles de sécurité, notre mot de passe reste devinable en 2 minutes, en plus d’être compromis.
Ce genre d’estimateurs de force de mot de passe est très efficace techniquement, il nous suffit juste de l’implémenter dans nos formulaires en adaptant le message et l’interface pour amener, de la façon la plus claire possible et avec le minimum de friction possible, l’utilisateur à prendre une bonne décision.
L’utilisateur peut également en parallèle mettre des cartes de son côté en utilisant un gestionnaire de mot de passe utilisant ces deux solutions. Il y en a beaucoup sur le marché et nous ne les citerons pas tous mais voici les principaux que nous avons rencontrés qui répondent à ces critères : 1Password, Bitwarden, Dashlane, NordPass, …
Pour les prochains exemples, nous allons prendre «P@ssword!123» et «exactchevalbatterieagrafe», sa traduction française :
Faisons maintenant un tour d‘horizon sur les sites web des grands acteurs connus, pour comparer les résultats de leurs indicateurs de force de mot de passe avec nos 2 derniers résultats de NordPass :
Tout d’abord, vous pouvez déjà retourner voir les deux premières photos de l’article, la SNCF et la Poste, et ensuite…
La SNCF –
LeBonCoin –
Ameli –
Bref, les services français ont du retard, pas étonnant que nous ayons tant d’identifiants compromis… Et pour finir l’implémentation correcte de GitHub :
Pour conclure sur toutes ces choses que nous avons apprises ici, aucun blâme n’est lancé. Les problèmes présentés ici sont des responsabilités partagées entre les développeurs et les utilisateurs : c’est aux utilisateurs de ne pas utiliser de mots de passes faibles ou compromis et de ne pas les réutiliser sur plusieurs sites, mais c’est également notre responsabilité d’acteurs du numérique de concevoir des solutions résistantes aux bourrages d’identifiants, d’aider les utilisateurs à faire de meilleurs choix de mots de passe, mais également d’éduquer nos utilisateurs sur l’utilisation d’outils tels que les gestionnaires de mots de passe qui régleraient bien des soucis ! Car après tout : le seul mot de passe sécurisé est celui dont vous ne vous souvenez pas !