J'ai fait un test il y a quelques mois. J'ai pris un mot de passe de 8 caractères ("crypto42"), je l'ai hashé en MD5, et j'ai lancé une recherche dans une rainbow table en ligne. Résultat : 0,3 seconde pour retrouver le mot de passe en clair. Pas 30 secondes, pas 3 secondes. Trois dixièmes de seconde. Si votre mot de passe sur un vieil exchange utilise un hash non salé, c'est le temps qu'il faut pour le craquer.
C'est quoi une rainbow table
Une rainbow table est un fichier précalculé qui contient des millions (parfois des milliards) de correspondances entre des mots de passe et leurs hashs. Au lieu de calculer le hash de chaque combinaison possible à chaque tentative (comme dans une attaque brute force), l'attaquant cherche directement le hash dans sa table. C'est une attaque par recherche, pas par calcul.
Le concept a été proposé par Philippe Oechslin en 2003. L'idée repose sur un compromis temps-mémoire : vous dépensez beaucoup de temps et d'espace disque pour construire la table une fois, puis chaque craquage est quasi instantané. Une rainbow table complète pour les mots de passe alphanumériques de 8 caractères en MD5 fait environ 460 Go. C'est gros, mais ça tient sur un disque dur ordinaire.
Pourquoi c'est pertinent pour la crypto
Les exchanges et services crypto stockent les mots de passe sous forme de hash (en théorie). Si un exchange se fait compromettre par une injection SQL ou une autre faille, l'attaquant récupère les hashs, pas les mots de passe en clair. Mais avec une rainbow table, retrouver le mot de passe à partir du hash est trivial si le hash n'est pas salé.
Le salage (salt) consiste à ajouter une valeur aléatoire unique au mot de passe avant de le hasher. "crypto42" + salt "x7q9" donne un hash complètement différent de "crypto42" seul. Comme le salt est différent pour chaque utilisateur, l'attaquant devrait construire une rainbow table par salt, ce qui rend l'approche impraticable.
Le problème : tous les services n'utilisent pas le salage. Les petits exchanges, les projets DeFi lancés à la va-vite, les plateformes de NFT développées par deux stagiaires, ça existe. Et quand leur base de données fuite, les rainbow tables fonctionnent parfaitement.
MD5, SHA-1, bcrypt : tous les hashs ne se valent pas
MD5 et SHA-1 sont considérés comme obsolètes pour le stockage de mots de passe. Ils sont rapides à calculer, ce qui est une qualité pour vérifier l'intégrité d'un fichier mais un défaut pour le stockage de mots de passe. Plus le hash est rapide à calculer, plus la rainbow table est rapide à construire et à interroger.
bcrypt, scrypt et Argon2 sont les standards actuels. Ils sont volontairement lents (paramétrable) et incluent un salt intégré. Une recherche dans une rainbow table bcrypt n'a aucun sens parce que chaque hash est unique grâce au salt, et le temps de calcul rend la construction de la table impraticable.
Si vous demandez à un exchange quel algorithme de hashing il utilise et qu'il ne sait pas répondre, c'est un signal d'alarme. Les plateformes sérieuses comme Kraken ou Binance utilisent bcrypt ou des équivalents.
Comment vous protéger
Utilisez des mots de passe longs et aléatoires. Plus le mot de passe est long, plus la rainbow table nécessaire est grande. Au-delà de 12 caractères mixtes, les rainbow tables deviennent trop volumineuses pour être pratiques. Un gestionnaire de mots de passe génère et stocke ces mots de passe pour vous.
Ne réutilisez jamais vos mots de passe. Si votre mot de passe fuite d'un service qui utilise MD5 sans salt, et que vous utilisez le même sur Coinbase, l'attaquant n'a pas besoin de rainbow table pour votre compte Coinbase. Il utilise directement le mot de passe en clair.
La double authentification est votre filet de sécurité. Même si votre mot de passe est cracké via rainbow table, le 2FA empêche l'accès au compte. C'est la dernière barrière, et elle fonctionne.
Stockez le gros de vos fonds hors exchange, sur un hardware wallet. C'est la seule garantie que vos fonds ne dépendent pas de la sécurité (ou de l'insécurité) d'une plateforme tierce.
