Le tableau de la résistance des mots de passe

⚠️ Le blog a été déplacé vers le site Patrowl, vous serez redirigé automatiquement dans 3 secondes, sinon cliquez sur ce lien : https://patrowl.io/le-tableau-de-la-resistance-des-mots-de-passe/
👍 Vous y retrouverez toutes les nouvelles publications

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

https://twitter.com/Gendarmerie088/status/1303213404669308928

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 😉).

Hors ligne vs En ligne

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 ».

Attaques « Hors ligne »

Ceci a déjà été abordé par la présentation que j'avais faite à l'OSSIR en mai 2019 ainsi que sur le blog de GreenLock, 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 réalisée sur le mot de passe adjoint d’un diversifiant ou diversificateur ("salt" en anglais), élément supplémentaire, unique pour le mot de passe et permettant d’empêcher tout 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, de signature… mais pour faire simple, parlons de condensats, car les techniques de cassage sont finalement similaires.

D’où viennent ces condensats

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…)
• …

Comment casser ces condensats

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, dériver avec des jeux de règles.

Attaques exhaustives (brute force)

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 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, principalement 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.

Attaques « en ligne »

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 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 😉.

Conclusions

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.

> Donc avec "CM#Apollon1980", je suis bien. En revanche, oubliez "ilovecats"

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)

> Pas trop, c’est bien souvent inutile de « casser » un mot de passe en 2020. Lutter contre la réutilisation c’est plus important.

Oui oui oui !

> L’idéal étant d’utiliser l’authentification à deux facteurs: mot de passe + une autre méthode d’authentification.

Re-oui oui oui !

> Bonjour @AXAFrance, les mots de passe de votre espace client peuvent être craqués "immédiatement". Nous, clients, espérons que vous allez corriger le tir.

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).

> Mais Kevin Mitnick montre qu’on peut casser un mot de passe complexe en quelques secondes

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 😉.

> Petit truc intéressant supplémentaires, il est facile d'avoir des mots de passe différents sur chaque sites. 1 - Avec gestionnaire de mot de passe, 2 - En ajoutant le nom du site à un mot de passe de base. Alors, pour la deuxième technique, ça ne sert que dans un cas particulier

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.

> Y a qqs boites de sécu en France qui t’ouvrent 16 char/num/min/MAJ/spéciaux en 15 minutes. Et ils (la police judiciaire) ont des moyens forensic pour se dispenser de s’occuper du mdp.

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.