Web3智网

從 Keplr 事件看錢包恢復機制:助記詞、雲端備份與分片的信任邊界

原文作者劉教鏈在 2026 年 11 月 10 日刊出的文章中指出,Keplr 社交登入錢包發生資產遭轉走事件,涉及數千個帳戶,官方將原因指向 Web3Auth 的基礎設施漏洞。依原文描述,受影響者多數是使用 Google 或 Apple 登入建立錢包的使用者。

原文刊出時,事故的具體技術原因尚未詳細披露。 以下是作者對四種私鑰保管與恢復策略的比較,不應視為已確認的事故調查結果。討論範圍也不包含由中心化交易所直接掌握全部資產控制權的託管方案。

紙本助記詞:風險集中在使用者的保管方式

作者先以使用者自行抄寫、保管助記詞作為比較基準。這種方式的安全邊界較直觀:使用者必須避免紙本遺失、受損、被拍照或洩露給他人。

它的弱點也集中在人為保管上,例如抄錯、搬家遺失、火災,或被家人當作廢紙丟棄。作者看重的不是紙本沒有風險,而是使用者比較容易理解風險位於何處,以及自己需要保護什麼。

Uniswap 錢包:雲端存密文,恢復仍需獨立密碼

依作者描述,Uniswap 錢包的做法是將助記詞加密後,備份至使用者自己的 iCloud 或 Google Drive。恢復時,使用者需要登入雲端帳戶,再輸入當初用於加密助記詞的密碼;這個密碼與 Apple ID 密碼不同。

在這套設計中,雲端服務商取得的是密文,理論上無法直接解開。作者列出的風險包括雲端帳戶遭盜用、驗證碼被攔截、密碼遭釣魚網站騙取,以及雲端儲存服務本身遭入侵。取得加密備份與成功解密,仍是不同的環節。

相較於紙本保管,這種方式將部分風險移至雲端帳戶、加密密碼與服務商的安全性。

MetaMask 社交登入:線上恢復與離線攻擊的差別

依原文介紹,MetaMask 社交登入方案會將加密後的助記詞存放於自身伺服器,並把解密金鑰拆成分片,交由不同伺服器節點保存。恢復時,需要 Google、Apple 或 Telegram 的登入憑證,以及使用者設定的密碼。

作者轉述 MetaMask 的說法指出,即使伺服器遭入侵,攻擊者取得分片後仍須破解密碼。他進一步區分兩種情境:

  • 正常的線上恢復流程:登入憑證、服務端速率限制與密碼,構成不同層次的防線。
  • 分片節點失守後的離線攻擊:作者分析,若攻擊者取得所需分片並能在自己的設備上嘗試破解,服務端速率限制便不再有效,密碼強度會成為關鍵防線。

這是作者對設計風險的分析,並非原文披露的 MetaMask 遭駭事件。

Keplr:分片數量不等於控制權彼此獨立

原文將 Keplr 採用的方案描述為三片式設計:一片位於使用者設備、一片位於雲端伺服器,另一片作為恢復備份;登入後由伺服器參與重組,任意兩片即可恢復私鑰。

作者提出的核心疑問是:如果其中兩片實際由同一家服務商控制,表面上的分片門檻是否會退化為單一服務商的突破口?

劉教鏈懷疑這可能與事件有關,但也明確表示,仍須等待廠商披露更多技術細節。因此,「同一家服務商控制兩片」在原文中是風險假設與事故推測,不能當作已證實的失竊原因。

比較重點:便利性降低人為失誤,也引入服務依賴

作者認為,從紙本助記詞、雲端加密備份,到社交登入與分片恢復,系統增加的元件未必能讓使用者更容易理解安全邊界。登入服務商、雲端儲存、分片節點與恢復流程,都可能成為需要信任的環節。

不過,原文也承認這些設計有其目的:自行保管助記詞的人為失誤風險很高,社交登入能降低其中一部分失誤,代價則是引入服務商風險。作者指出,使用者往往無法看見或驗證兩類風險的實際機率。

因此,這篇比較更適合用來檢視錢包的信任邊界,而非據此排出四種方案的確定安全名次:私鑰或助記詞存在哪裡、誰控制恢復所需的條件,以及服務端失守後還剩下哪些防線,才是作者希望使用者能夠理解的問題。


原文作者:劉教鏈
原文刊出時間:2026 年 11 月 10 日 14:04:29(UTC+8);本文保留該報導時點的資訊與未確認狀態。
原文來源:〈從錢包被盜看四種安全策略〉,深潮 TechFlow