---[ Rainbow Tables et support des caractères spéciaux sous Windows ]--- ---[ 1. Introduction ]-------------------------------------------------- Le principe de tables Rainbow [1] est connu depuis longtemps et leur efficacité sur des algorithmes sans graines (LM, NT, etc.) ou avec des graines liées à l'identifiant (Oracle, MScash, etc.) ne se dément plus. RainbowCrack [2] a été le premier logiciel implémentant le principe des Rainbow Tables, suivi du logiciel OphCrack [3] qui apportait certaines optimisations. Même des logiciels très populaires et accessibles à tous comme Cain & Abel [4] ont intégré le support des Rainbow Tables. Les tables disponibles publiquement ([5], [6] entre autres) sont systématiquement générés pour des caractères anglo-saxons. Cette brève détaille l'implémentations de caractères spéciaux, tels que les accents français, dans RainbowCrack et apporte des recommandations pour le stockage des empreintes sous Windows et le choix des mots de passe. Elle fait suite à une intervention réalisée à la SSTIC07 lors des Rump Sessions [7]. ---[ 2. Les empreintes des mots de passe sous Windows ]----------------- Deux algorithmes se côtoient pour le stockage non-réversible des mots de passe des utilisateurs déclarés sur des sytèmes d'exploitation de type Windows : Lan Manager (LM) et NT. 2.1 Les empreintes Lan Manager (LM) L'algorithme permettant le calcul des empreintes LM repose sur le chiffrement d'une chaîne connue par une clé générée à partir du mot de passe de l'utilisateur : Le détail de cet algorithme est le suivant : 1. Le mot de passe est tronqué à 14 caractères ; 2. Si il n'est pas assez long, il est complété avec des caractères nuls ; 3. Le mot de passe est simplifié : convertion d'une chaîne de caractères Unicode en une chaîne ASCII et simplication des caractères pour ne conserver que les caractères dits "OEM" [ avec entre autre la mise en majuscule systématique ] ; 4. Il est ensuite tronqué en deux parties de 7 caractères ; 5. Chaque partie indépendante est utilisée comme une clé de chiffrement DES 56 bits pour chiffrer la chaîne fixe "KGS!@#$%" ; 6. Les deux résultats de 8 octets sont concaténés pour donner l'empreinte LM de 16 octets. Les empreintes LM présentent plusieurs lacunes : - Non utilisation de graines ("seed" en anglais) permettant de réaliser des attaques par dictionnaires pré-calculés : principe des Rainbow Tables ; - Le mot de passe est de longueur bornée (14 caractères), la complexité est équivalente à deux mots de passe de 7 caractères de part la construction de l'empreinte LM ; - La complexité est diminuée du fait de l'utilisation de caractères OEM ; - Il est possible de savoir très facilement si le mot de passe fait moins de 7 caractères en comparant la seconde partie de l'empreinte par rapport à une certaine constante. Le nombre de combinaisons possibles est de 2 * 166^7 = 6,95 * 10^15 (il y a 166 caractères différents après convertion en OEM) 2.2 Les empreintes NT L'algorithme NT utilise la fonction de hachage MD4 pour générer une empreinte de 16 octets. Le mot de passe est ici limité à 128 caractères puis passé en Unicode, aucune simplification d'alphabet n'est nécessaire. Cet algorithme a été introduit à partir de Windows NT 3.5 côté postes serveurs et dans Windows Millenium côté postes clients. Une nouvelle fois, le calcul des empreintes NT ne fait pas intervenir de graine, rendant toujours possible la création de dictionnaires pré-calculés. Le nombre de combinaisons possibles est ici de 256^14 = 5,19 * 10^33 ce qui est sans comparaison avec le chiffre obtenu pour les empreintes LM. 2.3 La cohabitation des deux types d'empreintes Par défaut, les empreintes NT cohabitaient avec les empreintes LM jusqu'à Windows Vista. Windows Vista ne stocke plus ces empreintes LM mais les calcule toujours en mémoire comme l'a montré Aurélien Bordes lors de sa présentation intitulée « Secrets d'authentification sous Windows » au SSTIC07 [8]. Les empreintes stockées peuvent être révélées à l'aide d'outils spécifiques comme pwdump [9] ou fgdump [10] ou des outils plus polyvalents comme Cain & Abel [4]. ---[ 3. Rappel sur le fonctionnement des Rainbow Tables ]--------------- 3.1 Introduction Le principe de fonctionnement des Rainbow Tables est détaillé dans plusieurs articles ([1], [11] et [12] en particulier). Ce paragraphe a simplement comme vocation d'en extraire les grandes lignes. Plusieurs possibilités sont envisageables pour casser l'empreinte d'un mot de passe : - Calculer l'empreinte de chaque mot de passe "candidat" suivant l'algorithme utilisé et la comparer avec l'empreinte du mot de passe à casser pour savoir si le mot de passe a été découvert. Cette approche qu'on peut qualifier d'attaque exhaustive (brute-force) peut nécessiter un temps de calcul très important en fonction de la complexité des mots de passe. Dans la pratique, cette méthode est souvent précédée d'une attaque par dictionnaire. - Stocker tous les couples de mots de passe et d'empreintes associées dans des tables triées. Pour un jeu de caractères complexe, la quantité de mémoire nécessaire n'est plus dans le domaine du possible mais le temps de cassage des mots de passe est très faible. - Utiliser une méthode intermédiaire en stockant une partie des résultats dans des tables et en effectuant un minimum de calculs, c'est donc un compromis entre le temps (de calcul) et la mémoire. Le principe du compromis temps mémoire (time-memory tradeoff) a été inventé par Martin Hellman en 1980 et amélioré par de nombreux chercheurs. En 2003, Philippe Oechslin inventa une variante beaucoup plus rapide et démontra son efficacité pour le cassage des mots de passe (en particulier sur les empreintes LM Windows), il nomma les tables Rainbow Tables. La génération des tables est une opération coûteuse en temps (bien plus que le brute-force) mais rentable car le cassage des mots de passe est ensuite très rapide. Seuls les mots de passe générés à partir d'algorithmes sans graine (LM, NT, etc.) ou avec des graines liées à l'identifiant (Oracle, MScache, etc.) sont susceptibles d'être cassés via les Rainbow Tables. L'ajout d'une composante aléatoire (appelée graine ou sel) rend inutile les Rainbow Tables : c'est le cas par défaut sur les systèmes Linux avec l'utilisation de l'algorithme MD5 combiné à une graine. alice:$1$sVgP3DAm$68mmj7qv.PFAr6On2ZHx70:13025:0:99999:7::: ^ <------> <--------------------> | | |---------------- Empreinte | |-------------------------------- Graine |------------------------------------- Algorithme (MD5 ici) $ openssl passwd -1 -salt sVgP3DAm secret $1$sVgP3DAm$68mmj7qv.PFAr6On2ZHx70 La graine permet de diversifier l'empreinte comme le montre la commande suivante qui utilise le même mot de passe avec une autre graine : $ openssl passwd -1 -salt sVgP3DAp secret $1$sVgP3DAp$HSdu.x.OLdWufPBadkJPJ0 3.2 Un peu de théorie sur les Rainbow Tables (pour les gens courageux) Pour en revenir aux Rainbow Tables, la clé de voûte du compromis temps mémoire est l'utilisation d'une fonction de réduction pour générer des chaînes. Une fonction de réduction est une fonction arbitraire générant un mot de passe à partir d'une empreinte. Une chaîne est composée d'une succession d'empreintes et de mots de passe liés entre eux soit par une fonction de hachage (mot de passe -> empreinte) soit par une fonction de réduction (empreinte -> mot de passe). Le schéma suivant illustre ce principe : H R1 H R2 H R3 C1 : acd ---> h1 ---> dec ---> h2 ---> oef ---> h3 ---> aer La fonction de hachage (notée H) est dépendante de l'algorithme pour lequel les Rainbow Tables ont été calculées (LM, NT, MD5, SHA1, etc.), elle est unique pour toutes les chaînes et pour toutes les tables. La fonction de réduction (notée R) est une fonction surjective permettant de passer d'une empreinte donnée à un mot de passe dans le jeux de caractères (charset) choisi lors de la génération des tables. La spécificité des Rainbow Tables est d'utiliser une fonction de réduction différente à chaque étape des chaînes (d'où R1, R2, etc.) et pas uniquement différente entre les tables (comme c'était le cas dans les premières implémentations des compromis temps-mémoire). Seul le premier et le dernier mot de passe sont conservés dans les Rainbow Tables, les mots de passe et empreintes intermédiaires peuvent être retrouvés en appliquant la fonction de hachage et les fonctions de réductions successives. Plusieurs problèmes peuvent survenir dans les RainbowTables : - la fusion : se produit quand la fonction de réduction donne le même mot de passe pour deux empreintes différentes. Plus les chaînes sont longues et plus on a de chance qu'une nouvelle chaîne fusionne avec une chaîne déjà présente dans la table. Les mots de passe se trouvant après le point de fusion n'apportent donc pas de nouveaux mots de passe. L'utilisation de fonctions de réduction différentes à chaque étape des chaînes permet de n'avoir des fusions que si le même mot de passe redondant résulte de la même fonction de réduction. L'exemple suivant montre une fusion entre C2 et C1 au niveau de la fonction de réduction R2 : H R1 H R2 H R3 C1 : acd ---> h1 ---> dec ---> h2 ---> oef ---> h3 ---> aer C2 : tuk ---> h5 ---> zep ---> h6 ---> oef ---> h3 ---> aer ^^^ Fusion - une collision : c'est le cas d'une fusion qui intervient lorsque le même mot de passe redondant résulte de fonctions de réduction différentes. Les mots de passe se trouvant après le point de collision peuvent encore apporter de nouveaux mots de passe. L'exemple suivant montre une collision entre C3 et C2 (ou entre C3 et C1 d'ailleurs) au niveau de la fonction de réduction R1 : H R1 H R2 H R3 C1 : acd ---> h1 ---> dec ---> h2 ---> oef ---> h3 ---> aer C2 : tuk ---> h5 ---> zep ---> h6 ---> oef ---> h3 ---> aer C3 : bty ---> h7 ---> oef ---> h3 ---> tab ---> h8 ---> zab ^^^ Collision - les fausses alarmes : sont la conséquence d'une fusion quand on recherche le mot de passe correspondant à une empreinte donnée (Cf exemple dans l'explication d'une recherche dans les Rainbow Tables) Le principe de recherche dans les Rainbow Tables est assez simple à comprendre. Si on veut casser une empreinte donnée, il faut retrouver cette empreinte dans nos Rainbow Tables. Comme nous l'avons dit précédemment, seul le premier et le dernier mot de passe d'une chaîne sont conservés dans les tables. L'idée est donc de retrouver le plus rapidement possible la chaîne susceptible de contenir l'empreinte recherchée. Pour cela, il est nécessaire de recontruire petit à petit une chaîne à partir de notre empreinte en itérant successivement les fonctions de réduction et la fonction de hachage et en prenant soin de reconstruire cette chaîne candidate par la fin (afin d'optimiser les temps de calcul). Une comparaison est réalisée entre le mot de passe final de la chaîne candidate et les mots de passe de fin de chaîne des Rainbow Tables. Si aucun mot de passe ne correspond, il faut itérer à un rang supérieur (ie remonter à une fonction de réduction antérieure) sinon une chaîne devant contenir notre empreinte a été découverte. En reconstruisant la chaîne à partir du mot de passe initial, on est censé retrouver l'empreinte recherchée et le mot de passe associé. Mais deux cas de figures peuvent survenir en recalculant l'intégralité de cette chaîne : - l'empreinte recherchée peut y être découverte, le mot de passe associé est donc découvert ; - l'empreinte recherchée peut ne pas être présente, c'est possible si une fusion avec une autre chaîne est présente, on parle alors de fausse alarme et il faut recommencer la recherche ! Prenons un exemple avec les chaînes dont nous avons déjà parlé pour illustrer cette longue théorie sur la recherche dans les Rainbow Tables : H R1 H R2 H R3 C1 : acd ---> h1 ---> dec ---> h2 ---> oef ---> h3 ---> aer C2 : tuk ---> h5 ---> zep ---> h6 ---> oef ---> h3 ---> aer C3 : bty ---> h7 ---> oef ---> h3 ---> tab ---> h8 ---> zab ^^^ ^^^ Pour rappel, seul le premier et le dernier mot de passe sont réellement conservés dans les Rainbow Tables, le reste peut être recalculé rapidement, ce qui donne pour schématiser : C1 : acd - aer C2 : tuk - aer C3 : bty - zab Supposons que nous voulions casser l'empreinte h6. On commence par appliquer la dernière fonction de réduction (R3 dans notre exemple) sur l'empreinte que nous recherchons : R3 h6 ---> nfy Le mot de passe obtenu ("nfy") ne correspond à aucun mot de passe de fin chaîne contenu dans nos tables, il faut donc remonter à la fonction de réduction précédente (R2) : R2 H R3 h6 ---> oef ---> h3 ---> aer Cette fois-ci, le mot de passe obtenu ("aer") correspond au mot de passe final de la chaîne C1. En reconstruisant la chaîne initiale nous devrions trouver l'empreinte h6 et le mot de passe associé (celui qui nous intéresse) : H R1 H R2 H R3 C1 : acd ---> h1 ---> dec ---> h2 ---> oef ---> h3 ---> aer ^^^ Malheureusement, l'empreinte h6 ne fait pas partie de cette chaîne, une fusion a eu lieu au niveau de la fonction de réduction R2 (l'empreinte h2 est aussi réduite en "oef"). Nous sommes donc en présence d'une fausse alarme, il faut continuer la recherche dans les chaînes suivantes. La chaîne C2 a aussi comme mot de passe de fin de chaîne "aer" mais cette fois-ci l'empreinte h6 est présente dans la chaîne qu'on génère : H R1 H R2 H R3 C2 : tuk ---> h5 ---> zep ---> h6 ---> oef ---> h3 ---> aer ^^^ Le mot de passe recherché est donc celui ayant généré l'empreinte h6 via la fonction de hachage H, soit "zep". Pour accélérer la recherche dans les Rainbow Tables, les chaînes d'une table sont triées d'après leur fin. Enfin pour en terminer avec la théorie, il existe des Rainbow Tables "parfaites" dans lesquelles toutes les chaînes fusionnant sont supprimées. Pour compenser le nombre de mots de passe uniques supprimés avant la fusion, il est nécessaire de générer plus de chaînes ce qui allonge sensiblement le temps de calcul. En revanche, le temps de recherche dans ces tables est réduit et leur efficacité supérieure. Des sites communautaires de génération de tables [5] ont maintenannt tendance à les privilégier. ---[ 3. Découverte des caractères OEM associés ]------------------------ Les caractères spéciaux, et en particulier les accents, ne sont pas découverts avec les Rainbow Tables classiques car celles-ci n'ont pas été générées avec le bon jeu de caractères (charset). Il ne suffit pas de rajouter les accents dans son jeu de caractères pour découvrir les mots de passe en contenant. Comme expliqué au chapitre 2.1, le mot de passe Unicode saisi par l'utilisateur est tout d'abord simplifié pour ne conserver que les caractères "OEM". Ce sont ces caractères OEM qu'on retrouve dans les Rainbow Tables. La création d'un jeu de caractères adapté passe donc par la découverte d'une table de correspondance entre les caractères spéciaux et les caractères OEM associés. Là où ça se complique un peu, c'est que la simplification vers les caractères OEM va dépendre de la page de code (code page) OEM du système, c'est à dire concrètement de la langue du système. Par exemple, la simplification OEM ne donnera pas forcément le même caractère OEM sur un Windows français, anglais, allemand ou autre ... La table de correspondance peut être obtenue : - D'une manière qu'on pourrait qualifier d'empirique : on extrait sur un Windows d'une langue donnée les empreintes LM de mots de passe d'1 caractère comportant le caractère spécial qui nous intéresse. Les empreintes sont ensuite cassées vis à vis d'une Rainbow Table générée sur un charset complet et un nombre de caractères restreint. Il est alors possible de faire l'association entre le caractère OEM découvert dans les Rainbow Tables et le caractère ASCII spécial qu'on avait saisi dans notre mot de passe. - D'une manière beaucoup plus rationnelle : des recherches poussées sur l'authentification Windows ([8] et [14]) ont permis de révéler des fonctions d'API Windows non documentées parmis lesquelles : * RtlUpcaseUnicodeStringToOemString (ntdll.dll) : fonction documentée convertissant une chaîne de caractères ASCII (le mot de passe en l'occurence) en chaîne de caractères ASCII simplifiée comportant que des caractères OEM ; * SystemFunction006 (advapi32.dll) : fonction convertissant une chaîne de caractères ASCII OEM en empreinte LM. La connaissance de ces fonctions (et en particulier de la première) permet d'obtenir très rapidement les caractères OEM pour un code page donné. La table de correspondance présentée au paragraphe 4 détaille les résultats obtenus sur des Windows en langue française et anglaise. On s'aperçoit par exemple que pour le caractère "è" [0xE9] on obtient le caractère OEM "E" [0x45] sur un Windows anglais et "Ô" [0xD4] sur une version française. Par contre le caractère "é" [0xE9] donne le caractère [0x90] sur les Windows anglais et français. Une fois que les tables ont été générées avec le bon charset, seul un problème d'affichage dans RainbowCrack subsiste. Des modifications mineures du code (pour les versions 1.2 ou 1.2a) permettent d'obtenir un affichage satisfaisant et la bonne du casse du mot de passe. Le patch correspondant est publiquement disponible [0]. ---[ 4. Table de correspondance ] -------------------------------------- Les recherches précédentes permettent d'obtenir la table de correspondance suivante : ASCII ASCII OEM EN ASCII OEM FR -------- -------- -------- à [0xE0] A [0x41] · [0xB7] À [0xC0] A [0x41] · [0xB7] â [0xE2] A [0x41] ¶ [0xB6] Â [0xC2] A [0x41] ¶ [0xB6] ç [0xE7] [0x80] [0x80] Ç [0xC7] [0x80] [0x80] é [0xE9] [0x90] [0x90] É [0xC9] [0x90] [0x90] è [0xE8] E [0x45] Ô [0xD4] È [0xC8] E [0x45] Ô [0xD4] ê [0xEA] E [0x45] Ò [0xD2] Ê [0xCA] E [0x45] Ò [0xD2] ë [0xEB] E [0x45] Ó [0xD3] Ë [0xCB] E [0x45] Ó [0xD3] ï [0xEF] I [0x49] Ø [0xD8] Ï [0xCF] I [0x49] Ø [0xD8] î [0xEE] I [0x49] × [0xD7] Î [0xCE] I [0x49] × [0xD7] ô [0xF4] 0 [0x4F] â [0xE2] Ô [0xD4] 0 [0x4F] â [0xE2] ù [0xF9] U [0x55] ë [0xEB] Ù [0xD9] U [0x55] ë [0xEB] ü [0xFC] [0x9A] [0x9A] Ü [0xDC] [0x9A] [0x9A] û [0xFB] U [0x55] ê [0xEA] Û [0xDB] U [0x55] ê [0xEA] ÿ [0xFF] Y [0x59] Y [0x59] Les Rainbow Tables supportant les accents français pour des Windows anglais et français devront donc être générées à partir d'un charset comportant 13 caractères OEM supplémentaires : 0x80, 0x90, 0x9A, 0xB6, 0xB7, 0xD2, 0xD3, 0xD4, 0xD7, 0xD8, 0xE2, 0xEA, 0xEB. Le choix d'un charset pertinent et raisonnable va surtout dépendre de la puissance de calcul disponible pour les générer. Un charset de 69 caractères (équivalent aux tables lm_alpha-numeric-symbol32-space) comportant les ponctuations et caractères spéciaux les plus courants est un choix judicieux pour un premier jeu de tables avec accents. D'autres caractères spéciaux potentiellement intéressants sur un clavier français sont accessibles facilement (ceux imprimés sur les claviers français classiques), ils sont au nombre de 6. La découverte des codes OEM associés à ces caractères est laissée aux lecteurs persévérants :-) On notera bien évidemment que d'autres caractères (AltGr + ou Alt + ) sont possibles mais que ceux-ci représentent en pratique un très faible pourcentage de caractères découverts dans les mots de passe. ---[ 5. Recommandations ]----------------------------------------------- On sait depuis longtemps que les empreintes LM font parti des "vieilles casserolles" que se trimballe Windows depuis des années. On pensait le problème réglé avec la sortie de Windows Vista mais les empreintes LM sont toujours calculées et présentes en mémoire. Il est donc possible de les extraire pour l'ensemble des sessions actives sur un système compromis (Cf §8.1 de l'article [8]) et ce, quelque soit le système Windows compromis (Vista compris). Sur les systèmes antérieurs à Windows Vista, il est néanmoins recommandé de ne plus stocker les empreintes LM [15] au niveau de la SAM locale et de l'Active Directory et de supprimer celles existantes : soit en forçant les utilisateurs à changer leur mot de passe une fois le stockage des empreintes LM empêché, soit en les supprimant manuellement à l'aide d'un outil comme ThashLM [16] (outil non supporté par Microsoft). Il est aussi recommandé, dans la mesure du possible [17], d'éviter les authentifications LM et NTLMv1 pour privilégier l'authentification NTLMv2. Même si les recommandations précédentes ne sont pas appliquées, il est toujours possible d'empêcher le stockage des empreintes LM en : - choisissant un mot de passe de 15 caractères minimum ; - en utilisant le caractère euro dans un mot de passe, quel que soit sa longueur. Après avoir supprimé les empreintes LM, une politique de mot de passe d'une longueur de 9 ou 10 caractères avec 3 critères de complexité apparait être un bon compromis ... les Rainbow Tables NT avec un jeu de caractères conséquent (lettres, chiffres) ne dépassant - pour l'instant - pas 9 caractères. ---[ 6. Disponibilité des tables ]-------------------------------------- Les tables calculées NE SERONT PAS distribuées par HSC, que ce soit en direct sur le site www.hsc.fr ou par le biais de logiciels P2P (Bittorrent ou autres). Néanmoins, cette brève détaille toutes les informations pour les calculer soit-même et obtenir un affichage correct dans RainbowCrack (Cf patch correspondant à cette brève [0] pour RainbowCrack 1.2 & 1.2a) ---[ 7. Conclusion ]---------------------------------------------------- Cette brève montre comment implémenter des caractères spéciaux (accents ou autres) dans les Rainbow Tables. Elle met aussi en évidence la corrélation entre la langue du système et les caractères OEM générés. Avant la génération des tables Rainbow comportant ce type de caractères, il est donc indispensable de : - lister les caractères spéciaux qu'un utilisateur peut facilement utiliser ; - trouver les caractères OEM équivalents pour les langues fréquemment utilisées dans le pays ; - adapter le code source de Rainbowcrack pour obtenir un affichage satisfaisant de certains caractères. La connaissance du mot de passe en clair associé à une empreinte n'est pas nécessaire pour se connecter à distance sur un système Windows, le simple fait d'accéder aux empreintes permet de s'authentifier (Cf. outils de la suite pshtoolkit [18]). Néanmoins la connaissance des mots de passe en clair permet : - de pouvoir réutiliser les mots de passe découverts sur d'autres sytèmes ou applicatifs (très utile en test d'intrusion ...) ; - d'évaluer la qualité des mots de passe ; - de se construire de bons dictionnaires de mots de passe :-) - de passer de bons moments en voyant certains mots de passe :-) -- Guillaume Lehembre -- ---[ 8. Références ]---------------------------------------------------- - [0] Patch rainbowcrack pour supporter les caractères spéciaux français (accents ou autre) dans les Rainbow Tables http://www.hsc.fr/~lehembre/breves/rainbowtables/rainbowcrack-1.2-french-accents-HSC.diff - [1] « Making a Faster Cryptanalytic Time-Memory Trade-Off » - Philippe Oechslin - http://lasecwww.epfl.ch/pub/lasec/doc/Oech03.pdf - [2] Site officiel de RainbowCrack - Zhu Shuanglei http://www.antsight.com/zsl/rainbowcrack/ - [3] OphCrack (Implémentation optimisée du principe des Rainbow Tables par Philippe Oechslin - tables non compatibles avec celles de RainbowCrack) http://ophcrack.sourceforge.net/ - [4] Cain & Abel http://www.oxid.it/ - [5] FreeRainbowTables - Calcul communautaire de RainbowTables & RainbowTables en téléchargement libre http://www.freerainbowtables.com Mirroir en téléchargement direct : http://rainbowtables.ddl.cx/ - [6] RainbowTables du groupe Schmoo en téléchargement libre http://rainbowtables.shmoo.com/ - [7] « Rainbow Tables et caractères accentués sous Windows » - Rump Session SSTIC 07 - Guillaume Lehembre http://www.hsc.fr/ressources/presentations/sstic07_rump_rainbow/ - [8] Secrets d'authentification sous Windows - SSTIC07 - Aurélien Bordes http://actes.sstic.org/SSTIC07/Authentification_Windows/SSTIC07-Bordes-Secrets_Authentification_Windows.pdf http://actes.sstic.org/SSTIC07/Authentification_Windows/SSTIC07-article-Bordes-Secrets_Authentification_Windows.pdf - [9] pwdump6 - fizzgig http://xxx.foofus.net/~fizzgig/pwdump/ - [10] fgdump - fizzgig http://swamp.foofus.net/fizzgig/fgdump/ - [11] « Rainbow Tables : comment doper la vitesse de crackage des mots de passe » - Philippe Oechslin, Cédric Tissières - Hakin9 2/2007 (21) - [12] « How Rainbow Tables work » http://kestas.kuliukas.com/RainbowTables/ - [13] « Les compromis temps-mémoire et leur utilisation pour casser les mots de passe de Windows » - Philippe Oechslin, SSTIC04 http://lasecwww.epfl.ch/~oechslin/publications/sstic04.pdf - [14] Fonctions non documentées de l'API Windows - DreamPackPL http://www.d--b.webpark.pl/reverse01_en.htm - [15] Suppression des empreintes LM dans la base SAM locale ou dans l'AD http://support.microsoft.com/?kbid=299656 - [16] ThashLM - Outil de suppression des empreintes LM http://www.toolcrypt.org/index.html?thrashlm - [17] Limitations vis à vis du changement de valeur du paramètre LMCompatibilityLevel http://www.microsoft.com/technet/community/columns/secmgmt/sm1005.mspx - [18] Pass-The-Hash Toolkit http://oss.coresecurity.com/projects/pshtoolkit.htm