Depuis quelques années nous voyons régulièrement revenir un tableau, quelques fois mis à jour, qui indique le temps que met un pirate à trouver un mot de passe en fonction de la longueur et de la complexité de ce dernier. Ce tableau est même relayé par des institutions ainsi que par des influenceurs police/justice. Mais est-il vraiment fiable ?

La source

Ce qui est bien avec les comptes étatiques, c'est qu'ils citent leurs sources. En l'occurrence, il s'agit ici de Hive Systems, une société privée américaine proposant une vaste gamme de produits et services liés à la sécurité numérique.

En 2020, cette société a publié une première version du tableau, sans aucune explication. Elle a ensuite publié une première mise à jour en 2022, cette fois avec la méthodologie, ainsi qu'une seconde mise à jour en 2023, également avec la méthodologie.

Tout semble donc très sérieux : des données récentes et régulièrement mises à jour publiées par une société spécialisée dans le secteur d'après une méthodologie ouverte, le tout republié par des instances étatiques. C'est bon, on peut s’arrêter là, c'est fiable. Ou pas. Si vous lisez ce billet c'est bien qu'il y a un hic quelque part.

De quoi parle-t-on exactement ?

Commençons par une limitation clairement annoncée par Hive Systems et avec laquelle je suis entièrement d'accord : il s'agit ici uniquement du temps nécessaire pour casser l'empreinte d'un mot de passe.

Si jamais vous l’ignoriez, les mots de passe ne doivent jamais être stockés tel quel. Si c'était le cas, cela signifierait que toute personne ayant accès à la base de donnée, de manière légitime ou non, soit en mesure de connaître le mot de passe de chacun des utilisateurs. Entre les employés peu scrupuleux et les attaquants ayant trouvé une vulnérabilité, notamment une injection SQL, nos mots de passe se retrouveraient très souvent dans la nature.

Afin d'éviter ça, la pratique de très loin la plus courante consiste à « hacher » les mots de passe afin de ne stocker que leur empreinte numérique. Pour cela, on utilise une fonction de hachage cryptographique (il en existe des non-cryptographiques mais ce n'est pas le sujet), qui n'est rien d'autre qu'une méthode qui a certaines propriétés :

• elle est déterministe, c'est à dire qu'une même entrée donnera toujours la même empreinte ;
• elle résiste aux collisions, c'est à dire qu'il n'est pas possible de trouver deux entrées différentes donnant la même empreinte ;
• elle résiste à la préimage, c'est à dire qu'en connaissant l'empreinte il est impossible de retrouver l'entrée ayant permis de générer cette empreinte ;
• elle résiste à la seconde préimage, c'est à dire qu'en connaissant l'empreinte il est impossible de trouver une entrée présentant une collision avec l'entrée ayant permis de générer cette empreinte.

Un dernier point discuté dans la méthodologie et avec lequel je suis d'accord est le fait que le mot de passe peut ne pas être le seul élément garantissant la sécurité du compte. Par exemple, il peut être fait usage d'une authentification multifacteur. Cependant, cette dimension ne sera pas abordée dans la mesure où nous nous concentrons sur le temps nécessaire à casser un mot de passe d'après son empreinte.

Comment casse-t-on des empreintes de mots de passe ?

Le principe est simple : on hache toutes les entrées possibles jusqu'à ce que l'on trouve la même empreinte que celle dont on cherche l'entrée. C'est ce qu'on appelle une attaque par force brute.

Une telle attaque par force brute est la seule possibilité lorsque le mot de passe est généré par un générateur de nombres pseudo-aléatoires cryptographiquement sûr (CSPRNG). C'est là un des premiers problèmes que j'ai avec la méthodologie de Hive Systems : d'une part la société considère que les mots de passe sont générés par un CSPRNG et, d'autre part, les temps affichés sont ceux qui sont nécessaires pour hacher l'ensemble des entrées possibles. Ces deux points sont des failles majeures dans la méthodologie.

Tout d'abord, lorsque l'on commence à parler de la force d'un mot de passe généré par un CSPRNG, la bonne chose à faire n'est pas de tenter de calculer le temps qu'il faudrait pour le retrouver d'après une empreinte mais de calculer son nombre de bits d'entropie. Afin de savoir si la sécurité est bonne, on peut alors comparer avec le nombre de bits d'entropie minimal à utiliser pour les clés symétriques. Mais peut-être y-a-t-il un intérêt pédagogique pour le grand public ?

Et bien pas vraiment. Le cas ultra majoritaire dans lequel un mot de passe est généré aléatoirement est celui de l'utilisation d'une gestionnaire de mots de passe. Dans un tel cas, l'utilisateur générera systématiquement un mot de passe extrêmement robuste, sauf si la politique de mots de passe l'en empêche, notamment en imposant une longueur trop courte. Mais dans ce dernier cas il n'est pas possible de faire quoi que ce soit, donc l’intérêt pédagogique est inexistant. Il en est de même pour les rares systèmes qui imposent encore un mot de passe aléatoire à l'utilisateur.

Ceci dit, parlons maintenant du temps nécessaires pour hacher l'ensemble des entrées possibles. Le mot de passe étant aléatoire, il est extrêmement probable que l'on tombe dessus avant d'avoir testé toutes les entrées possibles. Il convient donc de ne pas considérer l'ensemble des entrées possibles mais seulement un pourcentage plus réduit. Un attaquant considérera sans doute un cas assez pessimiste (de son point de vue), de l'ordre de 75% afin d'ajuster les ressources qu'il peut consacrer à cette tâche. Un utilisateur, lui, devrait considérer un cas beaucoup plus favorable à l'attaquant, potentiellement de 25% à 50%, afin de limiter l'effet un coup de chance de l'attaquant.

Et l'humain dans tout ça ?

Comme vu précédemment, les attaques par force brute ne sont utiles que contre les mots de passe générés aléatoirement, mais également contre ceux de (très) faible longueur. Dès lors que c'est un humain qui choisis le mot de passe, il est bien plus rentable d'exploiter les différents biais cognitifs afin de ne pas avoir besoin de tester toutes les entrées, mais seulement celles qui ont le plus de chances de correspondre.

Pour ça, la première technique est d'utiliser des listes de mots. Ces listes sont généralement composées à partir de mots de passes précédemment cassés, mais également de mots du dictionnaire de la langue ciblée et de liste de prénoms. Plus un attaquant connaît de choses sur le profil des utilisateurs, plus il sera en mesure d'affiner sa liste de mots.

Et si vous pensiez lui échapper en modifiant astucieusement votre mot de passe, par exemple en insérant quelques caractères ou en en remplaçant certains par des symboles, sachez que les logiciels spécialisés dans le cassage des empreintes de mots de passe permettent de prendre ça en compte afin d'appliquer toutes ces différentes astuces. Oui, les attaquants professionnels ont largement étudié l'esprit humain et savent en tirer partit à leur avantage. Tout ça, Hive Systems en parle rapidement dans sa méthodologie en admettant qu'il s'agit effectivement d'une limitation. Mais ils sont encore bien loin du compte…

Les professionnels arrivent également à casser des mots de passe particulièrement longs, notamment des citations. Pour cela, ils construisent des modèles en se basant sur différents textes tels que des livres ou des discussions sur internet. C'est ainsi qu'en 2013 différents mots de passe allant jusqu'à 36 caractères étaient déjà cassés alors que, même en 2023, le tableau de Hive Systems indique encore que ces mots de passe mettent des dizaines de millions d'années à être cassé (les longueurs étant hors-tableau, j'extrapole les données).

Et si vous pensez que l'on a fait le tour de l'histoire, sachez que ce n'est que le début. Des chercheurs ont déjà travaillé sur l'entraînement d'une IA afin d'améliorer le cassage des mots de passes choisis par des humains. Avec la mode actuelle pour ces technologies, je pense que l'on peut prédire de nouvelles avancées dans le domaine.

De quels moyens disposent les attaquants ?

J'espère que vous ne croyez pas que le premier Jean-Kévin Haxxor dispose des mêmes moyens pour casser des mots de passe qu'un groupe criminel bien rôdé. Les cartes graphiques permettant des calculs d'empreintes en grand nombre, elles sont très prisées pour cet usage. Bien entendu, plus elles sont performantes et plus on en a, plus vite on cassera les mots de passe.

Pour être honnête avec Hive Systems, ils ont identifié cette limitation dans leur méthodologie. Cependant, ils ont fait le choix assumé de ne baser leurs calculs que sur l'utilisation d'une unique carte graphique du commerce et, pour les mises à jour, de faire évoluer le modèle. Lorsque l'on voit les fermes de cartes graphiques déployées pour miner des cryptomonnaies, comment peut-on sérieusement considérer que des groupes criminels n'utilisent qu'une unique carte graphique ?

Ceci dit, il convient de relativiser ce choix de moyens faibles. En effet, toute personne s'intéressant un peu aux compétitions de cassage de mots de passe (oui, ça existe vraiment) sait que ce n'est pas celui qui a le plus de cartes graphiques qui l'emporte. Ainsi, pour l'édition 2022 du challenge Crack Me If You Can, l'équipe Hashcat a remportée la compétition en utilisant 30 cartes graphiques haut de gamme, 40 cartes graphiques bas de gamme mais surtout beaucoup d'humains très compétents. Bref, c'est très peu par rapport aux fermes à shitcoins mais ça reste significativement plus que ce que nous propose Hive Systems. Notons qu'il y a tout de même des différences entre la compétition et la réalité, bien que l'on est pas forcément très loin non plus.

Comble de l'ironie : dans sa méthodologie de 2023, Hive Systems discute de ce qui pourrait être fait en faisant financer des milliers de cartes graphiques par des investisseurs sous prétexte d'entraînement d'une IA. Entraînement d'IA qui ne se fera pas vu que Hive Systems propose d'utiliser exclusivement ces ressources pour faire des attaques par force brute qui sont certainement bien moins efficace que ne l'aurait été une IA spécialisée dans le cassage de mots de passe…

Mais au fait, on utilise quoi comme fonction de hachage ?

Dans les fonctions de hachage cryptographiques, on trouve des fonctions dites « génériques ». En tant que tel, elles servent surtout à de la vérification d'intégrité. Lorsque l'on souhaite faire des choses plus intéressantes, il existe des fonctions spécialisées qui se basent bien souvent sur une fonction générique. En l'occurrence, pour calculer l'empreinte d'un mot de passe, il faut une telle fonction spécialisée.

Comme souvent avec la cryptographie, beaucoup de développeurs peu formés ont fait des choix désastreux. C'est ainsi que, malgré que l'on sache depuis au moins 1995 que ce n'est adapté, de nombreux développeurs ont utilisé la fonction de hachage générique MD5. Pour cette raison, Hive Systems utilise uniquement celle là dans ses tests.

Heureusement, contrairement à ce que soutient Hive Systems, cette fonction est de nos jours relativement peu utilisée. Plus aucun framework, CMS ou autre composant logiciel sérieux n'utilise ça de nos jours, il ne reste plus que quelques outils développés en interne pour encore l'utiliser. Ceci est dû non seulement au fait que les fonctions de hachage génériques ne sont pas adaptées à cet usage, mais également au fait qu'au cours des années 2000, des collisions ainsi qu'une attaque par préimage ont été découvertes pour MD5. Cette fonction n'est donc plus considérée comme cryptographiquement sûre depuis cette période.

De plus, en Europe, il existe un risque juridique sérieux pour les organismes qui utiliseraient une fonction de hachage générique pour calculer les empreintes des mots de passe. En effet, l'article 32 du RGPD impose de mettre en œuvre toutes les mesures de sécurité nécessaires pour garantir la sécurité des données personnelles. S'il n'y a pas de règle fixe sur ce qui doit être fait, il convient de se référer à l'état de l'art en la matière qui exclu formellement ce genre de mauvaise pratique (cf. recommandations de la CNIL et guide de l'ANSSI).

Bref, le choix de MD5 comme fonction de référence pour tableau est très contestable. Et pourtant, le choix de la fonction de hachage est absolument critique car, si les fonctions génériques sont étudiées pour êtres rapides, les fonctions dédiées au hachage de mots de passe sont elles étudiées pour être lentes afin de ralentir les attaquants. Les fonctions les plus récentes sont également conçues pour occuper un grand espace en mémoire afin de demander des ressources considérables aux attaquants.

Mais que faudrait-il choisir alors ? Et bien il n'y a malheureusement pas de réponse. Les fonctions spécialisées sont très différentes les unes des autres et permettent toutes de paramétrer les coûts en temps et/ou en mémoire. Ainsi, une même fonction peut, sur un même matériel et pour une même entrée, mettre un temps totalement différent suivant les paramètres qui lui sont passés.

Quelques ordres de grandeur afin que vous preniez bien conscience des différences de vitesse d'exécution. Avec ma vielle carte graphique, une AMD Radeon R9 380 achetée en 2016 (oui, je conserve mon matériel très longtemps), le benchmarking de hashcat me donne :

• 7 511 000 000 H/s pour MD5
• 3 867 H/s pour Bcrypt avec 32 itérations
• impossibilité de lancer Scrypt avec 16384 itérations à cause du manque de mémoire allouable sur la carte graphique ¯\_(ツ)_/¯

Je précise que je ne parlerai pas de l'utilisation d'un sel cryptographique car le sujet de l'attaque simultanée de plusieurs mots de passes n'est pas abordé dans le tableau. Mais sachez que ça existe et que, contrairement à l'ensemble des fonctions dédiées au hachage de mots de passes, MD5 ne permet pas d'en intégrer un de manière correcte bien que certaines personnes bricolent des mécanismes pour (mal) le faire.

Bref, ça n'a strictement aucun sens de parler de temps de cassage d'un mot de passe de manière générique, suivant la fonction de hachage utilisée ça change énormément. Ne pas non plus vouloir considérer le coût en mémoire est également une erreur, c'est refuser un élément de sécurité présent sur toutes les fonctions apparues depuis à peu près les 15 dernières années (par exemple, Scrypt est apparue en 2009).

Conclusion

Et bien au final ce n'est pas très brillant. L'étude de la seule attaque par force brute n'a aucun intérêt, les biais humains ne sont pas du tout pris en compte, les moyens des attaquants non plus et il est fait comme si les méthodes actuelles de stockage de mots de passe n'existaient pas. C'est pitoyable. La gestion des mots de passe est un sujet éminemment complexe et sérieux avec lequel on ne peut pas vraiment se permettre des approximations hasardeuses. Pour ma part je ne m'attendais pas à une telle incompétence de la part de la société éditant ce tableau.

Notons qu'un tel tableau peut avoir un effet délétère sur la sécurité en faisant croire au grand public que certains mots de passe sont sécurisés alors qu'en réalité ils ne le sont pas. Nous l'avons particulièrement vu avec le cas du cassage de mots de passe particulièrement longs des années avant la première publication du tableau.

Serait-il possible de faire un tableau qui, lui, serait correct ou bien donnerait au moins une idée fiable de la situation ? À mon avis, non, ce n'est pas possible. Produire ce genre de torchon est, je pense, plus un coup de communication qu'autre chose et je regrette vraiment que l'on fasse de la publicité à une société privée de droit américain sous couvert de sécurité numérique.