Un wallet peut sembler complètement normal tout en ayant été vulnérable dès la création de sa phrase de récupération. La vulnérabilité RNG faible de CryptoJS montre pourquoi. Dans les versions concernées de CryptoJS, CryptoJS.lib.WordArray.random() utilisait une construction pseudo-aléatoire personnalisée alimentée par JavaScript Math.random(), et non une source aléatoire platforme cryptographiquement sécurisée. Cela compte car la sécurité cryptographique dépend de l'imprévisibilité à la source. L'enquête Ill Bloom a relié cette faiblesse d'implémentation à du code réel de génération de wallets. Dans les chemins de génération vulnérables, des demandes nominales d'entropie de 128 bits et 256 bits pour les wallets pouvaient se réduire à des espaces de recherche effectifs d'environ 2^39 et 2^47 possibilités. Les phrases de récupération résultantes pouvaient encore : • utiliser des mots BIP39 valides • passer la validation de somme de contrôle • dériver des comptes blockchain standards • signer des transactions valides • apparaître complètement ordinaires à l'utilisateur Voici la distinction cruciale : Une phrase de récupération valide n'est pas automatiquement une phrase de récupération générée en toute sécurité. Une autre nuance importante est que la détection d'une dépendance CryptoJS concernée ne prouve pas automatiquement qu'un wallet était exploitable. Les enquêteurs doivent établir si la fonction aléatoire vulnérable a effectivement généré des phrases de récupération, des clés, des jetons, des nonces ou d'autres secrets sensibles à la sécurité. CryptoJS 4.0.0 a remplacé le chemin de génération basé sur Math.random par des méthodes aléatoires cryptographiques natives. Mais mettre à jour une bibliothèque corrige la génération future. Elle ne peut pas rétroactivement ajouter de l'entropie aux phrases de récupération créées il y a des années. Importer une graine affectée dans un autre wallet logiciel ou matériel ne le répare pas non plus. Les mêmes clés sous-jacentes restent dérivables. La leçon de sécurité plus large dépasse CryptoJS. Les développeurs doivent auditer les flux réels de génération de secrets, y compris les dépendances directes et transitives, au lieu de s'appuyer uniquement sur les noms de paquets ou les analyses de dépendances de niveau supérieur. Pour les applications navigateur, Web Crypto expose crypto.getRandomValues() pour une aléatoire cryptographiquement forte. Node.js et les environnements mobiles fournissent leurs propres API cryptographiques sécurisées pour l'aléatoire. Les utilisateurs de wallets doivent se concentrer sur la provenance logicielle, l'historique de maintenance, l'historique de génération, l'aléatoire fiable et les sauvegardes sécurisées, plutôt que d'assumer qu'une phrase de 12 ou 24 mots est automatiquement sûre. Lisez l'analyse complète de TokenToolHub : https://t.co/2AjB3PrKIZ