# 无密码登录防钓鱼，但我的密钥到底存在哪？

**Summary:** 通行密钥能有效阻断常见的钓鱼攻击，却让用户对凭证存储位置和恢复机制一头雾水。只有当服务明确回答这两个问题时，我才愿意将其设为默认登录方式。

- Canonical: https://markhuang.ai/zh/news/passkeys-stop-password-phishing-key-custody
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-09-18
- Section: News
- Tags: 通行密钥, WebAuthn, 账户安全
- Source: [Ethan Hawksley](https://hawksley.dev/blog/i-dont-like-passkeys)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一把玻璃通行密钥打开安全门，身后路径分别通向手机、笔记本电脑、缠绕的连接线和上锁的恢复保险库](https://cdn.markhuang.ai/news/passkeys-stop-password-phishing-key-custody/hero.webp)

*登录可以很简单，但密钥到底归谁管，却被藏在后面。把通行密钥当成唯一入口之前，我想先搞清楚凭证究竟存在哪里。*

在 2026 年 9 月 18 日发表的[《我不喜欢通行密钥》](https://hawksley.dev/blog/i-dont-like-passkeys)一文中，Ethan Hawksley 认为，对于已经在用独立密码加 TOTP 应用的用户来说，换通行密钥是一笔别扭的交易。它确实能挡住常见的假登录页攻击，但也可能把你的访问权限绑到某个设备、某个凭证提供商，或者某个出了问题你才搞明白的恢复流程上。

他的诊断我基本同意，结论我却未必。通行密钥解决了密码一直解决不了的钓鱼问题，这种抵抗力我不会轻易丢掉。麻烦在于，产品弹窗通常只告诉你"登录更快"，背后的保管决策却被一笔带过。在服务催我切到无密码之前，我想先搞清楚三件事：通行密钥存在哪里、能不能加一条独立的备份路径、所有同步设备都丢了之后怎么办。

可移植性其实走得比原文说的更快。Bitwarden 现在已经在 [iOS 26+ 和 Android 14+](https://bitwarden.com/help/storing-passkeys/) 上支持通过 FIDO 凭证交换协议直接传输通行密钥，只要两端应用都支持就行。这是实打实的进步，虽然离"所有通行密钥在所有提供商间自由迁移"还有距离。

## 加密技术确实在发挥作用

通行密钥的优势不是营销话术。[WebAuthn Level 3 规范](https://www.w3.org/TR/webauthn/)描述的是绑定到特定网站的公钥凭证：服务端保存公钥，私钥由验证器保管。按规范的安全模型，后续认证可以抵御中间人篡改——给真网站创建的通行密钥，没法拿到仿冒域名上重放。

攻击者的账本因此变了。密码可以被复用——一个站泄露，其他站跟着遭殃；密码也可以被钓——用户心甘情愿地输进一个逼真的假页面。通行密钥两样都不行：它不能跨站复用，也没法被人手敲进错误的表单。[FIDO 联盟](https://fidoalliance.org/passkeys/)还区分了同步通行密钥和设备绑定通行密钥，这两条路的备份和可移植性完全不同。

分歧就在这里。拿通行密钥和"完美管理的随机密码 + 独立 TOTP"对比，基准设得太高了——现实中没多少人做得到。就连[Hacker News 那个偏怀疑的讨论帖](https://news.ycombinator.com/item?id=42442639)里，也有一个反驳反复被提起：通行密钥强制每个站点用独立凭证，大规模钓鱼的收益直接缩水，设备丢失和恢复的问题虽然还没解决好，但方向是对的。

## 密钥去了某个地方

别扭的地方在于，“创建通行密钥”听起来就是一步操作，但背后可能是完全不同的保管方式。凭证可能跟着操作系统账户同步，可能住在第三方密码管理器里，也可能绑死在一把硬件密钥上。这不是“存在哪儿”的偏好问题——它决定了哪家公司的账户、哪台设备、哪件实物会卡进你的登录链路。

Hawksley 对硬件密钥操作的担忧有道理。认真搞的话，你得在每个重要账户上注册多把密钥，然后自己记清楚哪个网站认哪把。可发现凭证还会占密钥的存储空间，不同型号容量又不一样——买一把硬件密钥并不能终结规划问题。

同步通行密钥用信任换便利。跨平台凭证管理器确实能让体验顺畅很多。[Ars Technica 的实测](https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/)里，作者存在 1Password 里的通行密钥在设备和浏览器间跑得很顺，但他也指出普通用户根本搞不清楚多出来的那层提供商是怎么回事。这种"好用但说不清"的结果我觉得很真实。凭证管理器可以是答案，但登录界面不该假装保管选择这回事不存在。

## 恢复机制仍是产品核心

通行密钥能锁好前门，但账户恢复可能留着侧窗。Google 自己的[通行密钥用户体验指南](https://developers.google.com/identity/passkeys/ux/user-journeys)建议服务在用户创建通行密钥账户时就定好恢复方式——电话、邮箱、社交登录或身份核验，看服务自己的情况。这条建议很务实，但也恰好印证了 Hawksley 的核心论点：WebAuthn 管不了"所有凭证都丢了之后，账户到底归谁"这件事。

于是出现两种截然相反的翻车方式。恢复口子开大了，访问能找回来，但通行密钥本想堵死的钓鱼路径又敞开了；口子收太紧，设备丢了或者被提供商锁住，账户就永远拿不回来了。没有一种通用配置能绕开这个取舍，每个服务都得自己选一条路，跟用户说清楚，并在出问题时兜得住。

> **Info:**
>
> 把通行密钥设为默认之前，我得先拿到五个答案：存在哪里、能不能再注册一把独立的、提供商能不能转走、丢了设备怎么撤销、以及兜底的恢复方式是哪条。

我想要的其实就是透明度，但大多数通行密钥弹窗几乎什么都不告诉你。Google 建议在账户设置里显示每把已注册通行密钥的来源，比如设备平台或第三方管理器。我觉得这些信息应该直接放在创建弹窗旁边，备份注册和恢复确认也一起塞进同一个流程里。等用户自己摸到安全设置页面就太晚了——很多人根本不会去。

## 我的默认是有条件的

如果服务能让我看清每一把已注册的凭证、允许我加一条独立的备用路径，并且在删掉密码之前把恢复机制讲明白，我就愿意用通行密钥。反过来，如果弹窗只说"新方法更方便"——尤其是那个托管着同步通行密钥的平台账户本身就不太好恢复——我会犹豫。

对产品团队来说，一次成功的 WebAuthn 验证只是起步。账户页面得说清楚每把密钥从哪来、支持多把通行密钥、能撤销，恢复策略也不能偷偷把安全底线拉低。这些还没做明白就催用户开通行密钥，等于让人接受一笔看不清单据的风险转移。

Hawksley 的文章之所以有效，是因为它拒绝将优雅的加密技术与完整的登录产品混为一谈。我对可移植性没那么悲观，尤其是现在凭证交换已出现在人们可用的工具中。不过，没有保管地图的无密码承诺我并不想要。我会继续使用通行密钥，但前提是能追溯回入口的路径。