Vous avez probablement lu que les sites web stockent votre mot de passe sous forme de "hash" plutôt que le vrai. Alors comment les attaquants qui volent ces hachages les retransforment-ils en mots de passe ? L'une des réponses les plus anciennes et les plus ingénieuses est la rainbow table, et la comprendre explique aussi pourquoi une petite technique, le salage, la neutralise discrètement.
Ce qu'est une rainbow table
Quand vous créez un compte, un bon site web ne stocke pas votre véritable mot de passe. Il stocke un hash : la sortie d'une fonction à sens unique qui brouille le mot de passe en une chaîne de longueur fixe, d'une manière qui ne peut pas simplement être inversée. Si quelqu'un vole la base de données, il obtient les hachages, pas les mots de passe, et il doit encore retrouver quel mot de passe a produit chaque hachage.
Une rainbow table est un moyen de le faire rapidement. C'est une table de correspondance massive et précalculée qui relie les hachages aux mots de passe qui les ont créés. L'attaquant effectue le coûteux travail de hachage à l'avance, le stocke de manière compacte, puis se contente de rechercher chaque hachage volé. C'est toute l'idée : dépenser du stockage maintenant pour gagner du temps plus tard.
Comment fonctionne l'attaque
Casser un hachage par brute force signifie hacher chaque essai possible en direct jusqu'à ce que l'un corresponde : correct, mais lent à grande échelle. Les rainbow tables accélèrent cela grâce à une astuce de stockage ingénieuse. Plutôt que d'enregistrer chaque hachage, elles construisent de longues chaînes d'étapes alternées de hachage et de "réduction" et ne stockent que le début et la fin de chaque chaîne. Cela garde une table autrement d'une taille impossible assez petite pour être utile. Pour casser un hachage volé, l'attaquant reconstruit la chaîne pertinente et récupère le mot de passe d'origine.
Pourquoi le salage les neutralise
Voici la partie importante, et la bonne nouvelle. Une rainbow table ne fonctionne que si un mot de passe donné produit toujours le même hachage. La défense est un sel : une valeur unique et aléatoire ajoutée à chaque mot de passe avant qu'il ne soit haché. Avec des sels par utilisateur, deux personnes ayant un mot de passe identique se retrouvent avec des hachages complètement différents, et une table précalculée ne vaut rien : l'attaquant aurait besoin d'une rainbow table distincte pour chaque sel possible, ce qui n'est pas réalisable.
Les systèmes modernes vont plus loin, en associant les sels à des fonctions de hachage délibérément lentes comme bcrypt, scrypt ou Argon2. Le hachage lent rend même la devinette en direct coûteuse, et le salage tue le raccourci du précalcul. Ensemble, ils font des rainbow tables une menace surtout historique : dangereuse contre les systèmes anciens ou mal conçus qui stockent des hachages non salés, mais neutralisée par quiconque effectue correctement le stockage des mots de passe aujourd'hui.
Comment elle se compare aux autres attaques
Il est utile de placer les rainbow tables à côté des attaques avec lesquelles on les confond souvent :
- Brute force hache chaque combinaison possible en direct jusqu'à ce que l'une corresponde : lent, neutralisé par des mots de passe longs. Voir ce qu'est une attaque par force brute.
- Dictionary attack essaie une liste de mots de passe probables au lieu de toutes les combinaisons : plus rapide, neutralisée en n'utilisant pas de mots de passe courants ou réutilisés.
- Credential stuffing rejoue de vraies paires identifiant/mot de passe fuitées : neutralisé par des mots de passe uniques. Voir ce qu'est le credential stuffing.
- Rainbow table précalcule le travail de hachage et le recherche : neutralisée spécifiquement par le salage.
Ce que cela signifie pour vous
Vous ne pouvez pas contrôler la façon dont un site web stocke ses hachages, et les sites réputés salent et utilisent déjà des hachages lents, ce qui stoppe net les rainbow tables. Ce que vous pouvez contrôler, c'est la seule chose qui limite les dégâts quand un site se trompe : un mot de passe unique et long sur chaque compte. Si un site stocke mal ses hachages et que ses mots de passe sont cassés, un mot de passe que vous n'avez utilisé nulle part ailleurs n'expose rien au-delà de ce seul compte. Un gestionnaire de mots de passe rend la génération et le stockage de ces mots de passe uniques sans effort, ce qui est l'enseignement pratique derrière chacune de ces attaques.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Verrouille tes comptes → NordPassMots de passe forts et uniques · scanner de fuites · offre gratuite→Questions fréquentes
Qu'est-ce qu'une rainbow table ?
Une rainbow table est une grande table précalculée qui fait correspondre des hachages de mots de passe aux mots de passe qui les ont produits. Les sites web stockent les mots de passe sous forme de hachages plutôt qu'en clair, de sorte qu'un attaquant qui vole la base de hachages doit encore retrouver les mots de passe d'origine. Au lieu de hacher chaque essai sur le moment, une rainbow table effectue ce travail à l'avance et stocke les résultats sous une forme compacte, ce qui permet à l'attaquant de rechercher un hachage volé et de trouver rapidement le mot de passe correspondant. C'est un classique compromis temps contre mémoire : un stockage énorme au départ en échange d'un cassage rapide ensuite.
Comment fonctionne une attaque par rainbow table ?
Les mots de passe sont généralement stockés sous forme de hachages, des brouillages à sens unique qui ne peuvent pas simplement être inversés. Pour les casser, un attaquant doit trouver quelle entrée produit un hachage donné. Calculer cela en direct pour des milliards d'essais est lent, donc les rainbow tables précalculent de longues chaînes d'étapes de hachage et de réduction et ne stockent que les extrémités, ce qui garde la table assez petite pour être exploitable. À partir d'un hachage volé, l'attaquant reconstruit la chaîne pertinente pour récupérer le mot de passe d'origine. Le hic, c'est que cela ne fonctionne que contre des hachages qui n'ont pas été salés individuellement.
Comment se défendre contre les rainbow tables ?
Avec un sel. Un sel est une valeur unique et aléatoire ajoutée à chaque mot de passe avant qu'il ne soit haché, de sorte que deux utilisateurs ayant le même mot de passe obtiennent des hachages complètement différents. Comme une rainbow table est précalculée pour des entrées non salées, un sel propre à chaque utilisateur la rend inutile : un attaquant aurait besoin d'une table distincte pour chaque sel possible, ce qui n'est pas réalisable. Le stockage moderne des mots de passe combine des sels par utilisateur avec des fonctions de hachage délibérément lentes comme bcrypt, scrypt ou Argon2, qui font ensemble des rainbow tables une menace largement historique plutôt qu'actuelle.
Rainbow table, brute force et dictionary attack : quelle est la différence ?
Les trois tentent de récupérer des mots de passe à partir de hachages, mais différemment. Une attaque par brute force calcule le hachage de chaque combinaison possible en direct jusqu'à ce que l'une corresponde : exhaustive mais lente. Une dictionary attack essaie une liste de mots de passe probables (mots courants et mots de passe fuités) plutôt que toutes les combinaisons. Une rainbow table précalcule le travail de hachage à l'avance et recherche les réponses, en échangeant du stockage contre de la vitesse. Le salage neutralise spécifiquement les rainbow tables, car il brise l'hypothèse selon laquelle le même mot de passe donne toujours le même hachage.
Dois-je encore m'inquiéter des rainbow tables ?
Pour vos propres comptes, indirectement. Vous ne pouvez pas contrôler la façon dont un site web stocke ses hachages, et les sites bien gérés salent déjà et utilisent des hachages lents, ce qui neutralise les rainbow tables. Ce que vous pouvez contrôler, c'est d'utiliser un mot de passe unique et long sur chaque site, de sorte que même si un site stocke mal ses hachages et se fait casser, le mot de passe exposé ne déverrouille rien d'autre. Un gestionnaire de mots de passe rend cela pratique.
