一個錢包可能看起來完全正常，但從其恢復短語創建的那一刻起就可能不安全。 CryptoJS 的弱隨機數生成器漏洞揭示了原因。 在受影響的 CryptoJS 版本中，CryptoJS.lib.WordArray.random() 使用了一種自定義的偽隨機結構，其種子來自 JavaScript 的 Math.random()，而非密碼學安全的平台隨機源。 這至關重要，因為密碼學安全性取決於源頭的不可預測性。 Ill Bloom 的調查將此實現弱點與實際的錢包生成代碼聯繫起來。在易受攻擊的生成路徑下，名義上要求的 128 位和 256 位錢包熵可能縮減為大約 2^39 和 2^47 種可能性的搜索空間。 由此產生的恢復短語仍可： • 使用有效的 BIP39 單詞 • 通過校驗和驗證 • 推導出標準的區塊鏈帳戶 • 簽署有效的交易 • 對用戶而言看起來完全普通 這是關鍵區別： 一個有效的恢復短語並不等於一個安全生成的恢復短語。 另一個重要細節是，發現受影響的 CryptoJS 依賴項並不能自動證明該錢包可被利用。調查人員需要確認該易受攻擊的隨機函數是否實際生成了恢復短語、密鑰、代幣、隨機數或其他安全敏感的秘密。 CryptoJS 4.0.0 已將基於 Math.random() 的生成路徑替換為原生密碼學隨機方法。但更新庫只能修復未來的生成過程，無法回溯為多年前創建的恢復短語增加熵值。 將受影響的種子導入其他軟體錢包或硬體錢包也無法修復它。底層密鑰仍可被推導出來。 更廣泛的安全教訓超越了 CryptoJS。 開發者需要審計實際的秘密生成數據流，包括直接和傳遞性依賴，而非僅依賴包名或頂層依賴掃描。 對於瀏覽器應用程序，Web Crypto 提供了 crypto.getRandomValues() 以實現密碼學強隨機性。Node.js 和移動環境也提供了各自的加密安全隨機 API。 錢包用戶應專注於軟體來源、維護歷史、生成歷史、可信的隨機性以及安全備份，而非假設任何 12 個詞或 24 個詞的短語都自動安全。 閱讀完整的 TokenToolHub 分析： https://t.co/2AjB3PrKIZ