50 亿 Passkey：无密码登录最难的其实是找回账号

你可能已经用指纹或面容登录过某个网站，却没有意识到：那一刻你并不是“把指纹交给了网站”，而是在让设备用一把私钥完成签名。Passkey 的核心变化，不是把密码换成了生物识别，而是把登录从“证明我知道一个秘密”改成了“证明我拥有一把与这个网站绑定的私钥”。

Passkey 到底替代了什么

传统密码登录至少有两份秘密：用户脑中的密码，以及服务器数据库里保存的密码验证材料。即使服务器不保存明文密码，攻击者仍可能通过钓鱼、撞库、键盘记录或社工拿到可用凭证。

Passkey 使用非对称密码学。注册时，设备生成公钥和私钥：公钥可以交给网站保存，私钥留在设备或平台的安全凭证系统中。登录时，服务器发送一个一次性的随机挑战，设备让用户通过指纹、面容或 PIN 解锁私钥，再对挑战签名。服务器只需用公钥验证签名。

这一步有两个容易混淆的细节。第一，指纹本身通常不会离开设备，网站拿到的是签名结果。第二，Passkey 不是一串可以复制到记事本里的字符，它是由凭证、网站域名、设备保护和用户验证共同组成的一次认证过程。

一次登录经历了哪些步骤

网站在注册和登录时分别使用 WebAuthn 的创建凭证与获取凭证流程。服务器不能只检查“签名对不对”，还要检查挑战是否刚刚生成、凭证是否属于这个账号、RP ID 是否匹配，以及用户验证状态是否满足当前操作的风险要求。

为什么它能抵抗很多钓鱼

Passkey 的防钓鱼能力来自“域名绑定”，不是来自指纹这个动作本身。假设用户进入了 paypaI.example 这样的仿冒网站，浏览器会把当前域名交给 WebAuthn。由于这个域名与真正注册凭证时的 RP ID 不同，浏览器不会拿出原网站的 Passkey。

这和密码管理器自动填充有相似效果，但边界更硬：密码可以被诱导输入，Passkey 的签名对象和域名会被协议层绑定。攻击者当然仍可诱导用户在假网站上注册一个新凭证，或者骗用户完成一笔已经被页面准备好的转账，因此 Passkey 主要解决的是身份凭证被窃取的问题，不会替产品解决授权和交易确认问题。

“无密码”之后，恢复账号变成了主战场

密码丢了，可以走邮箱、短信或人工客服找回。Passkey 丢失时，问题更复杂：它可能只存在于旧手机，也可能通过平台账号同步到了新设备，还可能是公司安全密钥上的设备绑定凭证。

常见的三种形态是：

• 同步型 Passkey：由平台的凭证管理器在用户设备间同步，换手机更方便，但账户恢复依赖平台账号和云端密钥保护。
• 设备绑定型凭证：私钥不离开硬件，适合高风险和企业场景，但设备损坏或遗失后必须有备用凭证。
• 混合策略：普通登录使用同步型凭证，提现、改安全设置等敏感操作要求额外的硬件密钥或重新验证。

真正成熟的产品会在注册时就引导用户添加第二台设备、备用安全密钥或受控恢复联系人，而不是等用户被锁在门外后才显示一个“联系客服”。恢复流程本身也必须防止成为绕过 Passkey 的后门：如果只要回答几个容易猜的问题就能重置高价值账号，那么最强的登录凭证也会被最弱的找回流程抵消。

开发时最容易漏掉的检查

服务端至少要把下面几类数据分开管理：凭证 ID、公钥、用户验证要求、创建时间、最近使用时间和撤销状态。不要把“拥有一个凭证”直接等同于“拥有所有业务权限”。

// 伪代码：登录成功只代表身份通过
const user = await verifyWebAuthn(response, challengeStore.get(sessionId));

if (!user) throw new Error('authentication failed');

// 转账、改绑设备等动作还要单独做授权和交易确认
return createSession({ userId: user.id, assurance: user.verificationLevel });

还要记录异常设备、异常地理位置、凭证撤销和恢复事件。Passkey 减少了密码泄露面，却没有消除会话劫持、恶意浏览器扩展、客服社工和业务授权错误。

记住这四句话

第一，Passkey 的本质是公钥凭证，不是“把指纹上传到云端”。第二，域名绑定带来防钓鱼能力。第三，同步和恢复决定了普通用户能不能真正用起来。第四，登录认证成功之后，转账、改密和导出数据仍然需要独立的授权判断。

进一步阅读：W3C WebAuthn 规范、FIDO Alliance 2026 年 Passkey 报告。