Le tableau de la résistance des mots de passe

J’ai récemment vu passer un tweet de la gendarmerie des Vosges sur la solidité des mots de passe contenant ce tableau :

Bien que très intéressant et donnant une bonne idée de la complexité qu’il faut donner à un mot de passe, cette information, sans contexte ni explication, est un peu trompeuse en donnant l’impression qu’un mot de passe de, disons 12 caractères, est suffisant.

Malheureusement c’est beaucoup plus complexe (comme souvent 😉).

Si vous attaquez un compte sur son mot de passe, il y’a deux catégories d’attaques :

• Les attaques « hors ligne » (offline), où vous disposez de quelque chose permettant d’essayer de casser (ou de retrouver) le mot de passe chez vous, sur votre infrastructure, sans interaction avec l’application, le site, le service… ;
• Les attaques « en ligne » (online), où vous essayez de trouver le mot de passe en attaquant un service en ligne, d’une application web, d’un compte sur le réseau… C’est de là que provient le principal souci du tableau, il ne concerne que le mode « hors ligne ».

Ceci a déjà été abordé par la présentation que j’avais faite à l’OSSIR en mai 2019 ainsi que sur l’article de blog “Casser des condensats de mots de passe… sans violence“, mais voici quelques rappels et compléments sur ces attaques.

Pour réaliser une attaque « Hors ligne », il faut avoir quelque chose qui permette de retrouver le mot de passe de l’utilisateur. En général, ce quelque chose est un condensat (“hash” en anglais) du mot de passe. Il s’agit généralement d’une transformation non réversible.

Parfois, elle est réalisée sur le mot de passe, adjoint d’un diversifiant ou diversificateur (“salt” en anglais). C’est un élément supplémentaire, unique pour le mot de passe, et permettant d’empêcher toute attaque de pré-calcul (les fameuses Rainbow Table) pour retrouver le mot de passe, à partir du condensat.

Il peut également s’agit de pré-calculs intermédiaires comme pour le WPA2 avec PMKID, d’une signature… mais pour faire simple, parlons de condensats, car les techniques de cassage sont finalement similaires.

Ces condensats peuvent provenir de plusieurs sources :

• Piratage d’un service ou site web et vol de sa base de données de condensats (si les mots de passe sont en clair, alors c’est déjà gagné 😉) ;
• Piratage de « quoi que ce soit » contenant des condensats de mot de passe (base ntds.dit Active Directory, fichier /etc/shadow, base SAM, MS-Cache, Défis-Réponse NTLM…) ;
• Interception réseau, d’ondes…
• Techniques spécifiques permettant de demander à récupérer des condensats (Kerberoasting, attaque en clair connu…) …

Il y’a deux principales familles :

• Les attaques exhaustives consistant à tester tous les mots de passe possibles (dont je considère que les Rainbow Table font partie, avec un beau raccourcis mais ce n’est pas le sujet ici et oui, je vais dire cela très souvent, désolé 😄) ;
• Les attaques par dictionnaire, se basant sur une liste prédéfinie de mots de passe, que l’on peut compléter, modifier ou dériver avec des jeux de règles.

C’est la technique la plus simple et souvent la plus longue, car elle consiste à prendre tous les mots de passe possible, à en générer le condensat avec le même algorithme que celui du condensat que l’on cherche à « casser » et à voir si les condensats résultants sont les mêmes (ce qui signifie que le mot de passe est le bon, moyennant les collisions assez peu probables sur des mots de passe).

Et c’est ici que le tableau cité plus haut trouve sa place avec plusieurs remarques :

• Que le mot de passe contienne un mot trivial ou des caractères aléatoires, cela revient presque au même, sauf à connaître à l’avance les types de caractères utilisés (minuscules, majuscules, chiffres, caractères spéciaux). Donc « coucou » aura en fait la même complexité que « $*2We@ ». Après, il est tout à fait possible de chercher d’abord les mots de passe avec de simples caractères, puis de monter en puissance avec des chiffres et caractères spéciaux ;
• Le temps de cassage va dépendre des capacités de calculs de l’attaquant, majoritairement basées sur des ordinateurs avec des cartes graphiques puissantes. En considérant les caractères classiques de l’alphabet, nous avons pour chaque longueur de mot de passe le nombre possibilités suivantes :

Temps de calcul sur mon PC portable pour l’algorithme de condensat SHA-2 256 bits, utilisé par beaucoup de sites web :

Temps de calcul sur notre machine dédiée au cassage pour l’algorithme de condensat SHA-2 256 bits :

Temps de calcul sur mon PC portable pour l’algorithme de condensat NTLM, utilisé par Microsoft pour stocker les mots de passe des utilisateurs :

Temps de calcul sur notre machine dédiée au cassage pour l’algorithme de condensat NTLM :

Globalement, les résultats sont assez similaires entre mon dernier tableau à celui cité en introduction. D’ailleurs, j’ai gardé la philosophie des couleurs mais entre immédiat et moins d’une heure, pour moi il n’y a pas de différence.

Vous avez également ces valeurs références de RandoriSec qui sont assez justes (sur un autre algorithme de condensat) :

Attaques exhaustives malines

Comme il est compliqué de retrouver des mots de passe longs, il existe plusieurs techniques que j’ai déjà détaillé (cf. « Casser des condensats de mots de passe… sans violence ») avec l’utilisation de masques, c’est-à-dire en limitant l’espace des possibles (les types de caractères) pour certaines positions, comme par exemple, tous les mots (existants ou non) capitalisés d’une certaine longueur et finissant par deux chiffres (ex : Sunday20! )

Attaques par dictionnaire

Pour réduire encore de champ des possibles, l’utilisation de dictionnaires complétés de règles de dérivation reste très efficace, principalement du fait que beaucoup de personnes utilisent des mots usuels pour leurs mots de passe, complétés de caractères spéciaux mais classiques et positionnés toujours au même endroit.

De plus, suite aux nombreuses fuites de données ayant eu lieu et à la diffusion de leurs bases de condensats ou carrément des mots de passe, la plupart des attaquants disposent de dictionnaires contenant beaucoup de vrais mots de passe, améliorant le cassage, là encore, je vous renvoie vers les différents articles cités.

Là, c’est un tout autre sujet et pour lequel le tableau cité en introduction peut prêter à confusion.

Lorsque l’on parle d’attaque « en ligne » cela signifie que nous essayons des mots de passe directement sur l’application, le site web, le service… L’attaquant est donc tributaire de plusieurs limites :

• Le temps de réponse du service en ligne, qui peut être partiellement contourné en parallélisant les tentatives ;
• Les limites imposées par le service en ligne (nombre de tentatives dans un laps de temps donné), qui peut être partiellement contourné en parallélisant sur des sources d’attaque différentes (en général, ces limites sont par adresse IP) ;
• Le blocage du compte après un nombre infructueux de tentatives d’authentification. Il n’est donc pas possible de tester 40 millions de mots de passe en quelques secondes. Le tableau en introduction est totalement hors sujet.

Voici les différentes attaques réalisables.

Attaques exhaustives

Il s’agit tout simplement de tester tous les mots de passe possible mais rarement envisageable du fait des limites cités ci-dessus. Avec un temps de réponses de 300ms (ce qui est déjà bien) tester juste 1 000 mots de passe prend déjà 5 minute sans paralléliser et s’il n’y a pas de limite.

Attaques par dictionnaire

Là encore, tout comme pour les attaques « hors ligne », il s’agit de tester le contenu de dictionnaires de mots de passe, avec ou sans règles de dérivation mais là encore, cette attaque est tributaire des limites cités ci-dessus.

Attaque exhaustives sur des services de test

Parfois, des services de test, de développement… ne disposent pas de certaines limites décrites plus haut et permettent donc de tester un grand nombre de mots de passe rapidement. Ce fut le cas en 2016 pour la plateforme « beta.facebook.com » .

Réutilisation de mots de passe (Password Reuse)

C’est la technique la plus classique : je trouve une fuite de données concernant un site A et j’essaie le mot de passe associé à votre compte sur un site B. Si vous avez utilisé le même mot de passe, dommage 😉.

Password Spraying (que j’ai parfois vu appelé Credential Stuffing)

Il s’agit principalement de tester peu de mots de passe mais sur un grand nombre d’utilisateurs, afin de ne pas être tributaire des limites citées plus haut. Plusieurs outils permettent d’automatiser cette attaque comme :

• SentryMBA
• OpenBullet (intégration avec Selenium pour reproduire le comportement d’un humain derrière son navigateur)
• Storm
• Snipr (permet de tester des combinaisons d’identifiants et de mots de passe sur des serveurs de messagerie type IMAP, SMTP …)
• Private Keeper
• Woxy

Chaque outil a ses avantages et ses inconvénients. Ils nécessitent une liste comptes, des mots de passe et une configuration spécifique au site ciblé :

• Champs du formulaire à renseigner ;
• L’action à réaliser en cas de succès (comme la réinitialisation du mot de passe) ;
• Une liste de proxy afin de ne pas lancer toutes ses tentatives depuis la même source d’attaque. Pour des particuliers, ces attaques sont de moins en moins efficaces par contre, pour des entreprises, testez « NomDeL’entreprise2020! » sur tous les utilisateurs d’une entreprise et vous aurez de grandes chances d’avoir plusieurs succès 👍.

Canaux cachés et oracles

Je ne vais pas détailler ces attaques souvent liées à des problèmes d’implémentation de la cryptographie qui ne se fait pas en temps constant, mais il existe d’autres techniques permettant d’obtenir des informations sur le mot de passe, aboutissant dans certains cas à la possibilité de le retrouver.

Jetons de session

Je ne vais également pas détailler ici toutes les techniques de prédiction de jeton de sessions, de déchiffrement de jeton… ce n’est pas le sujet ici 😉.

Voici quelques commentaires faisant office de conclusion, principalement en rapport avec les réponses sur le tweets de la gendarmerie des Vosges.

Pour en revenir au tableau de la gendarmerie et mon exemple d’introduction, si un mot de passe de 12 caractères se trouve dans un dictionnaire, alors il est facile à casser.

Tout comme un mot de passe de 9 caractères peut s’avérer difficile à casser, s’il est réellement complexe (avec une forte entropie). Tout va donc dépendre des informations à disposition de l’attaquant et du contexte.

Non, pas si ce mot de passe est dans un dictionnaire et merci pour l’idée, je l’ajoute à mes propres dictionnaires (tout du moins le « CM#Apollon » car l’année sera ajoutée par mes règles de dérivation)

Oui oui oui !

Re-oui oui oui !

Non, un attaquant ne pourra pas deviner votre mot de passe et s’authentifier à votre place sur Axa ou Facebook en 2 minutes, même si votre mot de passe fait 8 minuscules et majuscules (sauf s’il a déjà votre mot de passe).

Voici la vidéo de Mitnick présentant le casse d’un mot de passe complexe en moins d’une minute : https://www.youtube.com/watch?v=46ODE0bot1I&feature=youtu.be

Il génère un mot de passe qui parait solide mais en réalité qui ne l’est pas, puis il utilise l’outil hashcat avec un dictionnaire (non fourni) et des règles de dérivations (non fournies).

Ce mot de passe est écrit en « leet speak » c’est-à-dire en remplaçant certains caractères par des chiffres (cf. wikipedia), technique connues et l’outil hashcat embarque des règles de dérivation adaptées permettant de transformer, par exemple, « password » en « p4ssw0rd ». Ensuite, le dictionnaire et les règles de dérivation n’étant pas fournis, il est impossible de savoir si ce mot de passe (tout du moins partiellement) n’est pas déjà dans son dictionnaire. Il en est de même pour les règles de dérivation qui sont peut-être spécifiquement adaptées à cette démonstration 😉.

Et non le fait d’utiliser le même mot de passe avec en plus le nom du site est n’est pas une bonne idée. Si un attaquant regarde manuellement votre cas, il sera évident pour lui de trouver vos autres mots de passe.

Et non, les outils mentionnés (ici Cellebrite) utilisent principalement des vulnérabilités (ou techniques de contournement des protections) pour rentrer dans les équipements et demandent le plus souvent un accès physique (je ne vais pas parler ici des outils d’attaque sur iCloud comme ceux d’Elcomsoft).

La meilleure recommandation reste d’avoir un coffre-fort de mots de passe (Keepass, Bitwarden, Dashlane…) avec des mots de passe complexes (générés aléatoirement) et uniques par site/service, combinés à une authentification forte par double facteur.