Que sont les tables Rainbow et comment sont-elles utilisées?

Question

Où puis-je en trouver un? Y a-t-il un pot d'or à la fin?
Comment puis-je me protéger contre eux?

Cette question était Question de sécurité de la semaine de la TI .
Lisez le 09 sept. 2011 entrée de blog pour plus de détails ou soumettez le vôtre Question de la semaine.

Crunge · Accepted Answer

Les tables arc-en-ciel sont généralement confondues avec une autre technique plus simple qui exploite un compromis de stockage de temps de calcul dans la récupération de mot de passe: les tables de hachage.

Les tables de hachage sont construites en hachant chaque mot dans un dictionnaire de mots de passe. Les paires mot de passe-hachage sont stockées dans une table, triées par valeur de hachage. Pour utiliser une table de hachage, prenez simplement le hachage et effectuez une recherche binaire dans le tableau pour trouver le mot de passe d'origine, s'il est présent.

Les tables arc-en-ciel sont plus complexes. La construction d'une table Rainbow nécessite deux choses: une fonction de hachage et une fonction de réduction. La fonction de hachage pour un ensemble donné de tables arc-en-ciel doit correspondre au mot de passe haché que vous souhaitez récupérer. La fonction de réduction doit transformer un hachage en quelque chose utilisable comme mot de passe. Une fonction de réduction simple consiste à coder en base64 le hachage, puis à le tronquer à un certain nombre de caractères.

Les tables arc-en-ciel sont constituées de "chaînes" d'une certaine longueur: 100 000 par exemple. Pour construire la chaîne, choisissez une valeur de départ aléatoire. Ensuite, appliquez les fonctions de hachage et de réduction à cette graine et à sa sortie, et continuez à répéter 100 000 fois. Seules les graines et la valeur finale sont stockées. Répétez ce processus pour créer autant de chaînes que vous le souhaitez.

Pour récupérer un mot de passe à l'aide de Rainbow Tables, le hachage de mot de passe subit le processus ci-dessus pour la même longueur: dans ce cas, 100 000 mais chaque maillon de la chaîne est conservé. Chaque maillon de la chaîne est comparé à la valeur finale de chaque chaîne. En cas de correspondance, la chaîne peut être reconstruite en conservant à la fois la sortie de chaque fonction de hachage et la sortie de chaque fonction de réduction. Cette chaîne reconstruite contiendra le hachage du mot de passe en question ainsi que le mot de passe qui l'a produit.

Les points forts d'une table de hachage sont que la récupération d'un mot de passe est rapide comme l'éclair (recherche binaire) et la personne qui construit la table de hachage peut choisir ce qui y est contenu, comme les 10 000 premiers mots de passe. La faiblesse par rapport aux Rainbow Tables est que les tables de hachage doivent stocker chaque paire de hachage-mot de passe.

Les tables Rainbow ont l'avantage que la personne qui construit ces tables peut choisir la quantité de stockage requise en sélectionnant le nombre de liens dans chaque chaîne. Plus il y a de liens entre la valeur de départ et la valeur finale, plus les mots de passe sont capturés. L'une des faiblesses est que la personne qui construit les chaînes ne choisit pas les mots de passe qu'ils capturent, de sorte que Rainbow Tables ne peut pas être optimisé pour les mots de passe courants. De plus, la récupération de mot de passe implique le calcul de longues chaînes de hachage, ce qui rend la récupération coûteuse. Plus les chaînes sont longues, plus elles contiennent de mots de passe, mais plus de temps est nécessaire pour trouver un mot de passe à l'intérieur.

Les tables de hachage sont bonnes pour les mots de passe courants, les tables arc-en-ciel sont bonnes pour les mots de passe difficiles. La meilleure approche serait de récupérer autant de mots de passe que possible en utilisant des tables de hachage et/ou le cracking conventionnel avec un dictionnaire des N mots de passe les plus importants. Pour ceux qui restent, utilisez Rainbow Tables.

Mark Davidson · Answer

Il existe de nombreuses bonnes explications sur ce que sont les tables Rainbow, celle-ci Comment fonctionnent les tables Rainbow est particulièrement bonne. Aussi article Wikipedia a aussi une très bonne explication. Pour une lecture un peu plus approfondie, l'article définitif sur le sujet est Making a Faster Cryptanalytic Time-Memory Trade-Off .

Une explication simple des tables arc-en-ciel est qu'elles utilisent une technique de compromis de mémoire temporelle. Au lieu de prendre une valeur de hachage cible et un dictionnaire de mots, puis de hacher chaque mot et de faire la comparaison à la volée (approche par force brute en utilisant quelque chose comme John ), vous hachez à la place toutes les valeurs du dictionnaire à l'avance (cela peut prendre très longtemps en fonction de la taille du dictionnaire). Mais une fois que vous avez terminé, vous pouvez comparer autant de hachages que vous le souhaitez aux valeurs pré-hachées dans les tableaux Rainbow, ce qui est nettement plus rapide que de calculer à nouveau les hachages.

L'explication que j'ai écrite ici dans un effort pour être courte était trompeuse, car elle n'expliquait pas l'utilisation des réductions que les tables Rainbow utilisent. Pour une meilleure explication jusqu'à ce que je réécris ce bit, voir @ Crunge answer .

Vous pouvez soit générer les tables Rainbow vous-même en utilisant une application comme RainbowCrack ou vous pouvez les télécharger à partir de sources comme The Shmoo Group , Free Rainbow Tables project site Web, Ophcrack projet et de nombreux autres endroits en fonction du type de hachage pour lequel vous avez besoin de tables.

Pour se protéger contre une attaque basée sur Rainbow Table, la méthode la plus efficace pour la combattre consiste à s'assurer que chaque hachage d'un système est salé . Cela rend les tables Rainbow pré-générées inutiles et signifierait qu'un attaquant devrait générer un ensemble personnalisé de tables à utiliser contre les hachages ciblés, ce qui ne serait possible que s'il connaissait le sel.

Luc · Answer

But et pertinence

Les tableaux arc-en-ciel aident à casser les mots de passe difficiles, c'est-à-dire ceux qui ne peuvent même pas être trouvés dans un grand dictionnaire. Les mots de passe étaient historiquement stockés sous forme de hachages simples dans les bases de données, et c'est ce contre quoi les tables Rainbow sont efficaces: créer une seule table Rainbow (lente) et exécuter un nombre illimité de bases de données pleines de hachages (rapide).

De nos jours, de plus en plus de systèmes utilisent des algorithmes de stockage de mot de passe appropriés tels que Bcrypt, Scrypt ou Argon2. Voir: Comment [stocker] les mots de passe en toute sécurité? Ces algorithmes ne sont plus "vulnérables" aux tables Rainbow: puisque chaque hachage est unique, même si les mots de passe sont égaux, les tables Rainbow ne fonctionnent plus.

C'est pourquoi les tables Rainbow sont impopulaires aujourd'hui. Même si quelque chose de moderne comme Argon2 n'est pas utilisé, les développeurs savent généralement qu'ils devraient au moins utiliser un sel. C'est déjà suffisant pour rendre une table Rainbow inutile.

Comment ils travaillent

Création d'une table

Imaginez que nous créons une table Rainbow avec seulement deux chaînes, chacune de longueur 5. La table Rainbow est pour la fonction de hachage fictive MD48, qui produit 48 bits (seulement 12 caractères hexadécimaux). Lors de la construction de la chaîne, nous voyons ceci:

Chain 0: 0=cfcd208495d5 => z=fbade9e36a3f => renjaj820=7668b2810262 => aL=8289e8a805d7 => ieioB=2958b80e4a3a => WLgOSj Chain 1: 1=c4ca4238a0b9 => ykI4oLkj=140eda4296ac => Dtp=1b59a00b7dbe => W=61e9c06ea9a8 => 6cBuqaha=d4d2e5280034 => 0uUoAD

Nous commençons par 0 parce que c'est la première chaîne (nous avons juste besoin d'un peu de valeur pour commencer). Lorsque nous hachons cela avec MD48, cela se transforme en cfcd208495d5. Maintenant, nous appliquons une fonction "réduire" qui formate essentiellement ce hachage en un mot de passe, et nous nous retrouvons avec "z". Lorsque nous hachons à nouveau cela, nous obtenons fbade9e36a3f, puis réduisez-le à nouveau et obtenez renjaj820. Il y a encore quelques cycles et le résultat final est WLgOSj.

Idem pour la deuxième chaîne. Nous commençons juste avec une autre valeur et faisons la même chose. Cela se termine par 0uUoAD.

Notre table Rainbow complète est maintenant la suivante:

WLgOSj => 0 0uUoAD => 1

C'est tout ce que vous avez à stocker.

Recherche d'un hachage

Disons que nous avons trouvé un hachage en ligne, 7668b2810262. Faisons le crack en utilisant notre table!

Looking for hash '7668b2810262', reduced to 'aL'. hashed=>reduced 'aL' to ieioB hashed=>reduced 'ieioB' to WLgOSj Found a match, 'WLgOSj' is in our Rainbow table: WLgOSj => 0 The chain starts with '0'. Let's walk that chain and look for the hash. hashed '0' to cfcd208495d5 hashed 'z' to fbade9e36a3f hashed 'renjaj820' to 7668b2810262 That hash matches! Found the password: renjaj820

Pour jouer avec lui-même, les exemples ci-dessus ont été créés à l'aide de ce script Python: https://Gist.github.com/lgommans/83cbb74a077742be3b31d33658f65adb

Propriétés de mise à l'échelle

En bref:

Des recherches rapides signifient des tables plus grandes, en supposant que la couverture reste la même.
Une meilleure couverture signifie soit des recherches plus lentes, soit des tables plus grandes.
Des tables plus petites signifient soit des recherches plus lentes, soit une couverture pire.

Les sections suivantes supposent que le temps par hachage + réduction est de 1µs et ne tient pas compte des collisions. Ce sont tous des chiffres approximatifs, donnés à titre d'exemples et non de valeurs exactes.

Temps de recherche

Si une opération de hachage + réduction prend une microseconde, générer une table avec un million de chaînes et 10 000 réductions par chaîne prendrait environ 3 heures:
chain_length × chain_count / reductions_per_second / seconds_per_hour
= 10 000 × 1 000 000 / 1 000 000 / 3600 = 2,8 heures.

La recherche dans ce tableau prend en moyenne 10 millisecondes. En effet, nous devrons généralement passer par chain_length/2 réductions avant de trouver quelle chaîne contient le hachage. Par exemple, nous pourrions avoir à effectuer 3000 réductions sur un hachage avant de trouver une valeur qui est dans le tableau. Ensuite, nous devons refaire cette chaîne depuis le début jusqu'à ce que nous trouvions la valeur correspondante. Si nous n'avions qu'à faire 3000 pour le trouver dans notre tableau, alors nous devons faire 7000 réductions depuis le début pour arriver au bon point de la chaîne. Fondamentalement, nous effectuons autant d'opérations lors de la recherche que lors de la génération d'une chaîne unique. Par conséquent, le temps de recherche est de 10 000 fois par microseconde, ce qui correspond à dix millisecondes (ou une centiseconde, si vous voulez).

Exigences de stockage

Lorsque vous souhaitez créer une table de recherche complète et rapide pour une fonction de hachage, même MD5, vous avez toujours besoin de cent milliards de milliards de téraoctets de stockage. Ce n'est pas très utile. Mais que se passe-t-il si nous voulons couvrir uniquement les mots de passe en minuscules jusqu'à 10 caractères?

Si nous voulons passer au maximum 30 secondes à chercher un hachage, et en supposant que nous ayons besoin de 1 microseconde (un millionième de seconde) par hachage + cycle de réduction, alors nous pouvons avoir une longueur de chaîne de: 1 million × 30 = 30 millions. Il y a 26^dix (ou 10¹⁴) possibles mots de passe minuscules de 10 caractères, et par chaîne nous couvrons 30 millions de valeurs. Cela nous laisse avec 4 millions de chaînes. Nous savons que chaque chaîne n'a qu'une valeur de début et de fin stockée et que les valeurs sont de 10 caractères chacune. Donc 2 × 10 × 4 million = 76 Mio de données.

La génération de la table en itérant sur tous les mots de passe de 10 caractères prend beaucoup de temps: 30 secondes par chaîne, soit 4 millions de chaînes, soit environ 91 ans. Beaucoup de gens seraient intéressés par une telle table, cependant, donc en regroupant 1092 CPU (= 91 × 12), cela ne prend qu'un mois. Cela montre à quel point une telle table peut être comparée à l'espace de mot de passe qu'elle couvre: les recherches ne prennent que 30 secondes et vous ne devez stocker que 76 Mo de données.

Conclusion

Les tables arc-en-ciel peuvent être considérées comme un compromis temps-mémoire : on ne stocke qu'une petite partie de la table et la récupère grâce à un calcul supplémentaire sur le temps de recherche. Cela fait partie de la raison pour laquelle les sels, ou plutôt, un bon algorithme de stockage de mot de passe comme Scrypt ou Argon2 sont importants pour garder les mots de passe en sécurité. Une table Rainbow ne peut récupérer un mot de passe salé que si la table contient une entrée suffisamment grande pour contenir à la fois le sel et le mot de passe, ce qui serait extrêmement inefficace et va à l'encontre du but recherché.

Notez qu'une chose similaire s'applique au chiffrement: lorsque les gens chiffrent des fichiers avec un mot de passe, une table Rainbow peut être construite pour casser les fichiers. Disons que le logiciel utilise AES, et que le premier bloc du fichier devrait être décrypté en "passwordcorrect" en utilisant le mot de passe fourni par l'utilisateur, alors une table Rainbow utiliserait AES au lieu d'une fonction de hachage.

Chaque fois que vous manipulez un mot de passe (un secret de force inconnue, et surtout si l'utilisateur peut le réutiliser), exécutez-le toujours via un algorithme de stockage de mot de passe approprié (lent) pour le rendre lent et unique à craquer.