Quand un site vous annonce que votre mot de passe mettrait trois millions d’années à tomber, il oublie la partie importante de la phrase. La bonne question n’est pas combien de temps. C’est combien de temps face à quoi.
Et ce face à quoi, ce n’est pas vous qui le décidez. C’est un développeur de la boutique où vous avez acheté une paire de baskets en 2019, le jour où il a choisi comment ranger votre mot de passe dans sa base de données. Vous avez tapé exactement la même chaîne de vingt caractères sur les deux sites. Sur l’un elle tient des siècles, sur l’autre elle tombe avant le déjeuner.
Le chiffre qui manque à l’équation
Une attaque par force brute, c’est de l’arithmétique de comptoir : nombre de candidats à essayer, divisé par le nombre de candidats que l’on peut essayer par seconde. Le premier facteur dépend de votre mot de passe — sa longueur, son alphabet, sa présence ou non dans un dictionnaire. Le second n’a strictement rien à voir avec vous.
Ce second facteur dépend de deux choses : le matériel de l’attaquant et, surtout, la fonction avec laquelle le site a transformé votre mot de passe en la bouillie de caractères stockée dans sa table d’utilisateurs. Cette fonction s’appelle un hash, et toutes ne coûtent pas le même prix à calculer.
MD5 et SHA-1 ont été conçus pour être rapides. C’est une qualité : ce sont des fonctions de hachage à usage général, faites pour résumer des messages et vérifier une intégrité, et là, ce qu’on veut, c’est avaler un gigaoctet sans avoir le temps d’aller se faire un café. Quand quelqu’un les emploie pour stocker des mots de passe, la qualité devient le problème. Une fonction que vous pouvez calculer des millions de fois par seconde est une fonction que l’attaquant peut lui aussi calculer des millions de fois par seconde — et lui, il a des cartes graphiques et tout le week-end devant lui.
bcrypt et Argon2 ont été conçus dans l’objectif exactement inverse. Ils sont lents exprès, et — c’est là que c’est élégant — d’une lenteur réglable. Niels Provos et David Mazières ont présenté bcrypt en 1999 sous un titre qui dit tout : A Future-Adaptable Password Scheme. L’idée était que la fonction puisse devenir plus chère avec les années, au rythme où le matériel deviendrait bon marché. Argon2, vainqueur de la Password Hashing Competition en 2015, a ajouté un tour de vis : il ne coûte pas seulement du temps, il coûte de la mémoire, précisément ce que les GPU distribuent avec le moins d’enthousiasme.
Entre un hash rapide et un hash lent bien configuré, il n’y a pas une différence de quelques pour cent. Il y a des ordres de grandeur. Beaucoup.
Les benchmarks existent, et ils sont publics
Rien de tout cela n’est de la spéculation. Hashcat, l’outil que la moitié de la planète utilise pour casser des mots de passe — les gentils compris —, embarque un mode benchmark que n’importe qui peut lancer sur sa propre machine et qui mesure, algorithme par algorithme, combien de fois par seconde on peut calculer chacun. La communauté publie ces tableaux à chaque sortie d’un nouveau GPU.
Ce qui est intéressant dans ces tableaux, ce n’est aucun chiffre en particulier — qui périme d’ailleurs à chaque génération de matériel — mais l’écart entre les lignes. Vous triez la liste par vitesse et vous voyez MD5 tout en haut, sur sa planète à lui. Vous descendez, vous descendez encore, et tout au fond du tableau il y a bcrypt et Argon2, avec des valeurs qui ne ressemblent à rien de ce qui précède. C’est le même mot de passe. C’est le même GPU. La seule chose qui a changé, c’est la façon dont le site a décidé de le stocker.
C’est pour ça que « 3 millions d’années » sans préciser face à quel hash, c’est du marketing, pas une mesure. Autant annoncer que votre voiture met six heures à arriver sans mentionner la destination.
Hors ligne et en ligne : deux mondes qui ne se touchent pas
Il y a une deuxième distinction que presque personne n’explique et qui change le résultat tout aussi brutalement.
Dans une attaque en ligne, l’attaquant essaie des mots de passe contre le formulaire de connexion, comme le ferait un utilisateur. Le rythme n’est pas imposé par son matériel : il est imposé par le serveur. Il peut y avoir une limite de tentatives, un blocage temporaire, un captcha, un délai entre les requêtes, une alerte au bout de mille échecs venant de la même adresse. Face à un site correctement défendu, une attaque en ligne est lente, bruyante et assez bête. L’arithmétique est si défavorable à l’attaquant que la force brute pure ne se tente presque plus : on essaie les quatre mots de passe habituels contre des millions de comptes, ce qui est un autre jeu.
Dans une attaque hors ligne, l’attaquant a déjà le vidage de la base de données. Il le ramène chez lui. Là, plus de serveur, plus de limite de tentatives, personne pour regarder : il y a ses cartes graphiques et sa facture d’électricité. Il peut essayer pendant des mois sans que personne s’en aperçoive, et il saura tout seul qu’il a trouvé, en comparant des hashs. C’est là que le hash décide de tout, parce que le hash est littéralement la seule chose qui le freine.
Et soyons honnêtes sur les probabilités : le scénario hors ligne n’a rien d’exotique. C’est ce qui se passe chaque fois qu’une base de données fuite. Quand LinkedIn a perdu la sienne en 2012, l’analyse du vidage diffusé a montré que les mots de passe étaient stockés en SHA-1 sans sel : un hash rapide, privé de l’ingrédient qui empêche de précalculer des tables. S’ils sont tombés si nombreux et si vite, ce n’est pas seulement parce que les utilisateurs avaient mal choisi. C’est surtout à cause d’une décision d’ingénierie qu’aucun utilisateur n’a jamais vue.
Ce que nous faisons ici, et pourquoi nous le disons
Notre vérificateur part de l’hypothèse de 10¹² tentatives par seconde, hors ligne, contre un hash rapide. C’est écrit sur la page elle-même, sous le résultat, et pas par transparence décorative : sans cette donnée, le temps affiché ne veut rien dire.
C’est délibérément le mauvais cas. Nous supposons que la base de données a déjà fuité, que l’attaquant a du matériel sérieux, que le site a stocké votre mot de passe de la pire façon raisonnablement possible et qu’en plus il connaît votre alphabet et votre longueur. Si le site utilise bcrypt correctement configuré, le chiffre réel grimpe de plusieurs ordres de grandeur et votre mot de passe tient bien plus longtemps que ce que nous vous annonçons.
Nous préférons nous tromper de ce côté-là. Un vérificateur qui vous félicite se félicite lui-même.
La conclusion qui dérange
Votre mot de passe n’a pas un temps de cassage. Il a un temps de cassage pour chaque site où vous l’avez utilisé, et ce temps est fixé par des gens que vous ne connaissez pas selon des critères qu’ils ne publient pas.
D’où deux conséquences, et ce sont toujours les mêmes. La première : puisque vous ne pouvez pas contrôler le hash, contrôlez l’entropie, la moitié de l’équation qui vous appartient — c’est pour ça que le générateur vous affiche des bits et pas un pourcentage sympathique. La seconde, et la plus importante : si chaque site a son propre mot de passe, celui qui l’a stocké en MD5 ne peut offrir que celui de ce site-là.
Parce que le maillon faible, ce n’est pas votre mot de passe. C’est le pire site où vous l’avez tapé.
Sources : benchmarks publics de hashcat (hashcat -b), consultables et reproductibles · N. Provos et D. Mazières, « A Future-Adaptable Password Scheme », USENIX, 1999 · Password Hashing Competition, remportée par Argon2 en 2015 · le modèle de menace déclaré dans le vérificateur de password.es : 10¹² tentatives/s, hors ligne, hash rapide · fuite LinkedIn de 2012 : l’entreprise a confirmé la brèche, et l’usage de SHA-1 sans sel a été établi en analysant le vidage publié.