原文作者：刘教链
原文发布时间：2026 年 11 月 10 日 14:04:29（UTC+8）
钱包能否通过社交账号登录，并不能直接回答资产由谁控制。更关键的问题是：助记词或密钥分片存在哪里，恢复私钥需要谁参与，以及哪些环节失守后可能影响资产安全。
刘教链以 Keplr 社交登录钱包的资产被转走事件为切入点，对比了纸质助记词、加密云备份及两类社交登录方案。以下事故信息与技术描述均来自该文；其中，Keplr 事件的具体成因尚未详细披露，作者的推测不能视为已确认结论。
Keplr 事件：已报道的信息与尚未确认的原因
据原文描述，Keplr 社交登录钱包有几千个账户的资产被转走，官方将原因指向 Web3Auth 的基础设施漏洞。受影响用户大多通过 Google 或 Apple 登录创建钱包。
原文没有提供具体损失金额，也没有披露完整的攻击路径。作者提到厂商之间存在责任争议，因此，不能仅凭这篇文章确定漏洞发生在哪个组件、攻击者如何获得控制权，或各方应承担什么责任。
四种方案，四类信任边界
1. 纸质助记词：保管责任集中在用户
传统自托管方式由用户抄写助记词并妥善保存，不依赖在线服务来恢复钱包。原文强调的基本习惯是：不要遗失，不要拍照，也不要向他人透露。
这种方式的优势在于保管对象直观、责任边界清晰；弱点同样集中在人这一端。抄写错误、遗失、火灾或日常搬运中的疏忽，都可能破坏备份。
作者以此作为比较基准，并非说明纸质保管没有风险，而是强调用户更容易理解自己需要保护什么。
2. Uniswap 钱包：云端保存密文，用户保管解密密码
按原文描述，Uniswap 钱包可将助记词加密后备份到用户自己的 iCloud 或 Google Drive。恢复时，需要登录云账户，再输入专门用于加密助记词的密码；该密码与 Apple ID 密码并非同一个。
在这一描述下，云服务商保存的是密文，而不是可直接使用的助记词。风险涉及云账户安全、钓鱼、验证码被截取、加密密码泄露，以及云存储服务自身遭到攻击。
这里需要区分两件事：攻击者取得加密备份，并不等于已经解密助记词。云账户和加密密码分别承担不同的保护作用。
3. MetaMask 社交登录：登录凭证、密码与分片节点共同参与
原文介绍，MetaMask 社交登录方案将加密后的助记词保存在自己的服务器上，并将解密密钥拆分到不同服务器节点。恢复时，需要 Google、Apple 或 Telegram 的登录凭证，以及用户设置的密码。
据作者转述，MetaMask 表示，即使服务器遭到攻破，攻击者仍需破解用户密码。作者进一步区分了两种攻击环境：
- 在线恢复时，登录验证和服务端速率限制可构成额外门槛。
- 若攻击者取得足以进行离线尝试的分片材料，在线速率限制便无法约束其本地穷举，密码强度的重要性随之上升。
这一讨论的重点，是不要把在线恢复流程中的限制，直接等同于服务器失守后的保护能力；它并不是对某次已发生攻击路径的确认。
4. Keplr 所用方案：分片数量之外，还要看实际控制方
按原文描述，Keplr 所用方案将密钥拆成三片：一片位于用户设备，一片位于云端服务器，一片作为恢复备份；任意两片即可恢复私钥，登录后由服务器参与重组。
作者提出的疑问是：如果其中两片实际都由同一家服务商控制，那么“两片即可恢复”的门槛，是否会退化为对单一服务商的依赖？
刘教链怀疑此次事故可能与这一问题有关，但明确表示，真实原因仍需等待厂商披露更多技术细节。这是作者的假设，不是已证实的漏洞结论。
便利性降低了哪种风险，又引入了哪种依赖？
原文的核心判断是：增加登录服务、云存储、分片节点和恢复流程，并不意味着信任需求消失了；它可能只是从用户手中的备份，转移到了更多服务和组织之间。
不过，作者也承认，引入这些机制有现实原因：完全依靠用户保管助记词，可能因抄错、遗失或误丢而失败。社交登录旨在降低这类操作失误，代价是增加服务商一侧的风险。两类风险各有多大，普通用户往往难以观察或验证。
因此，这篇文章更值得保留的问题，不是简单地按组件多少给钱包安全性排序，而是追问恢复流程中的控制关系：密文由谁保存，分片由谁掌握，密码在哪些情况下成为关键防线，以及多个名义上的环节是否实际依赖同一家服务商。
作者最后强调，钱包应当让用户看清私钥的保管与恢复边界。对于自托管的判断，不能只看产品名称或宣传口号，还要看谁能参与恢复、谁能实际获得资产控制权。