2. 密码认证的困境

在进入 Passkey 的工程实现之前，必须先回答一个更基础的问题：我们为什么非要迁移？如果传统密码、短信 OTP、TOTP 已经"够用"，Passkey 就只是一个时髦名词。事实恰恰相反——这三类方案在安全性和体验上都存在结构性缺陷，而这些缺陷正是 Passkey 要解决的核心目标。

一、核心原理：三类方案的信任基础各不相同

理解攻击面，先要理解每种方案"信任什么"。

• 传统密码：信任"只有用户知道这个字符串"。服务器存储密码哈希，登录时比对。信任基础是秘密的保密性。
• 短信 OTP：信任"只有用户能收到这条短信"。验证码通过运营商网络下发，信任基础是SIM 卡与手机号的绑定关系。
• TOTP：信任"只有用户持有这个共享密钥"。客户端与服务端基于同一密钥和时间戳计算一次性码，信任基础是共享密钥不被泄露。

三者的共同点是：都依赖一个可被复制、可被转发、可被诱导交出的秘密。这是它们所有攻击面的根源。

二、常见攻击面：从钓鱼到 SIM 劫持

下面这张表把三类方案的主要攻击面对齐，便于横向比较。

其中实时钓鱼中继最值得警惕：攻击者搭建与真实站点几乎一致的页面，用户输入密码后，攻击者立即用该密码登录真实站点，触发真实 OTP，再诱导用户把 OTP 填进假页面。整个链路中，密码和 OTP 都是"真实有效"的，传统风控几乎无法识别。这类攻击对短信 OTP 和 TOTP 同样有效，因为验证码本质上是可被转述的字符串。

三、用户体验问题：安全成本被转嫁给用户

安全方案若体验差，用户会用脚投票，最终反而降低整体安全水位。三类方案的体验痛点非常具体：

1. 密码记忆负担：复杂度要求、定期更换、不同站点不同密码，导致用户复用或写便签。
2. 找回流程脆弱：忘记密码后走邮箱或短信重置，重置链路往往比登录链路更弱，成为新的攻击入口。
3. 短信延迟与不可达：国际漫游、信号差、运营商拦截，都会让用户卡在验证码页。
4. TOTP 设备依赖：换手机、丢手机、恢复码丢失，都会导致账号无法登录，客服成本高。
5. 多步操作疲劳：输入密码、等待短信、切换 App 复制验证码，每一步都在流失转化。

四、迁移 Passkey 的动机：从"共享秘密"到"非对称密钥"

Passkey 的本质是把认证基础从"共享秘密"换成"非对称密钥对"。私钥永远留在用户设备的安全芯片中，服务器只保存公钥。登录时设备用私钥签名，服务器用公钥验签。

这一改变直接消解了前述攻击面：

• 无秘密可钓：钓鱼站拿到签名也没用，因为签名与真实站点的源绑定，无法转发到其他域。
• 无秘密可泄露：服务器侧没有可被拖库的密码或 TOTP 种子，公钥泄露无价值。
• 无秘密可复用：每个站点独立密钥对，撞库概念不成立。
• 体验更短：一次生物识别即可完成登录，无需记忆、无需等待短信。

下面是一段典型的 WebAuthn 注册阶段服务端返回的挑战参数，可以看到它不包含任何长期秘密：

{
  "challenge": "5f8a...随机32字节...",
  "rp": { "id": "example.com", "name": "Example" },
  "user": { "id": "dXNlci0x", "name": "alice", "displayName": "Alice" },
  "pubKeyCredParams": [
    { "type": "public-key", "alg": -7 },
    { "type": "public-key", "alg": -257 }
  ],
  "timeout": 60000,
  "attestation": "none"
}

挑战是一次性的，公钥参数是算法协商，用户标识是随机 ID。整个流程中，服务器从未接触过用户的私钥，也不存在"密码哈希"这种可被离线破解的资产。

五、误区与复盘：Passkey 不是银弹

在推动迁移时，团队常陷入几个误区，需要提前对齐预期：

• 误区一：Passkey 能立刻淘汰密码。现实是设备丢失、跨生态同步、旧设备兼容都需要回退路径，密码在过渡期仍会存在。
• 误区二：上了 Passkey 就不用管风控。Passkey 解决的是认证强度，账号恢复、异常行为、设备绑定仍需独立策略。
• 误区三：所有用户都能无缝迁移。企业内网、老旧浏览器、共享设备场景需要单独设计降级方案。