通行密钥用私钥签名完成认证，登录服务保存公钥。同步通行密钥可在设备间同步加密的凭据，设备绑定型则不同步。能否构成 MFA 取决于要求的用户验证，设备、同步账户和恢复流程仍需保护。
私钥不发送给登录服务
FIDO2/WebAuthn 使用密钥对。登录服务接收公钥并验证签名，不接收私钥。同步通行密钥可通过提供商同步加密的凭据，设备绑定型则保留在认证器中。同步账户和恢复流程也必须受到保护。
密码
你 和 服务器 共享同一个秘密。服务器泄露／在假网站输入就会被偷走
passkey
只有公钥泄露，无法生成登录所需的私钥签名。
「服务器上只有公钥」这一点很关键。公钥顾名思义就是可以公开的值，因此即使数据库泄露，单凭它本身也无法用来登录（这与密码的保存前提正好相反→ 什么是哈希化）。
与密码＋短信到底有何不同
密码＋短信验证码
- 共享秘密（密码）会泄露／因重复使用而连锁失守
- 在假网站输入时，连验证码一起被中间人转发
- 容易以「我自己能识破」为前提
passkey
- 只有公钥泄露，无法生成登录所需的私钥签名。
- 签名绑定到域名＝在假网站上无法成立
- 即使用户没察觉，机制上也会挡住假网站
中间人型钓鱼（AiTM）即使你小心翼翼地输入了正确的验证码，也会连那个验证码一起转发（→ 什么是钓鱼）。passkey 因为签名被绑定在域名上，从原理上堵住了这条路径。
passkey、双因素认证与硬件安全密钥的区别
passkey 既被说成「一种双因素认证」，又被说成「密码的替代品」，所以这些词容易混淆。按作用并列比较：
| passkey | 密码＋一次性密码 | 硬件安全密钥 | |
|---|---|---|---|
| 登录时用什么 | 签名绑定域名；要求用户验证时使用 PIN 或生物识别 | 记住的字符串＋验证码（通常 6 位） | USB/NFC 密钥内的私钥＋PIN 或触摸 |
| 服务器保存什么 | 公钥 | 密码哈希（身份验证器应用还要保存生成验证码的密钥） | 公钥 |
| 在假网站上使用时 | 签名无法完成 | 密码和验证码都可能被转发 | 签名无法完成 |
| 设备丢失时 | 同步 passkey 可在其他设备上使用 | 需要迁移身份验证器或使用恢复码 | 可能需要备用密钥或其他受支持的恢复方式 |
| 适合 | 几乎所有个人用途 | 尚不支持 passkey 的服务 | 管理员账户、高风险人群 |
支持 FIDO2 的硬件安全密钥可以保存不做云同步的设备绑定型通行密钥。准备备用密钥或服务支持的其他恢复方式有助于避免被锁在账户外。 什么是双因素认证 / 什么是一次性密码（OTP）.
同步 passkey 与设备绑定 passkey
passkey 按存放位置分为两种。
- 同步 passkey：保存在 iCloud 钥匙串、Google 密码管理工具或密码管理器应用中，在登录了同一账户的其他设备上也能使用。丢失一台设备也不容易被锁在门外
- 设备绑定 passkey：只保存在生成它的设备内，例如硬件安全密钥。因为不同步，你可以精确掌握它在哪里
NIST SP 800-63B-4（2025 年 7 月）允许在满足相关要求时于 AAL2 使用可同步认证器，包括用户验证和同步基础设施的保护。AAL3 还要求不可导出的密钥及其他控制，因此仅仅不同步并不保证合规。应结合所需保证级别、设备与同步账户的保护、恢复条件来选择。
添加 passkey 后仍然存在的弱点
即使 passkey 本身能抵御假网站，账户的强度也取决于最薄弱的那个入口。
- 密码登录仍然有效：在很多服务上，添加 passkey 后密码和短信验证码登录依然保留。假网站会索要剩下的那种方式，而不是 passkey
- 薄弱的恢复手段：如果账户恢复只需要短信或注册邮箱，那就会成为入口。用来恢复的邮箱账户本身也要用 passkey 保护
- 薄弱的设备锁：解锁设备后 passkey 就可以使用，所以不要用容易被猜到的锁屏 PIN
真实案例：证券账户被盗用与 passkey 强制化
2025 年，日本发生了大量案例：通过冒充证券公司的假网站窃取的登录 ID 和密码，被用来在他人的证券账户中进行未经授权的交易。日本金融厅在其提醒页面上表示，passkey 等抗钓鱼的多因素认证正在被强制化，并敦促用户尽快设置。
日本证券业协会（JSDA）修订了关于防止网上交易未授权访问的指南，自 2025 年 10 月 15 日起施行。它要求证券公司在登录、出金、变更出金银行账户等重要操作中实施抗钓鱼的多因素认证（例如基于 passkey 或 PKI 的认证），并默认将其设为必须。对于没有所需设备的客户，则提供其他多因素认证方式。
这个案例的两点教训：
- 行业从「依靠用户警惕」转向「依靠设计」：提醒大家识破假网站并没有止住损失，所以默认改成了在假网站上无法完成的认证
- 被点名的例子是 passkey 和 PKI，而不是由人读出并输入验证码的方式：NIST 同样指出，手动输入的一次性密码不可能具备抗钓鱼能力
作为证券账户的客户应采取的具体步骤——passkey 登录和交易通知——请参阅大和证券外包方遭未授权访问一文。
如何检查自己的账户和服务
确认重要账户是否支持 passkey
在邮箱、密码管理器、云、证券和银行、GitHub 账户的安全设置中查找「passkey（通行密钥）」选项。密码管理器的列表也会显示哪些服务已经保存了 passkey。
注册第二台设备或备用密钥
使用同步 passkey 时，确认它在登录了同一账户的另一台设备上可用。如果使用不同步的硬件密钥，注册一把备用密钥并存放在别处。
关上密码和短信这两扇侧门
添加 passkey 后，确认是否仍然只凭密码或只凭短信验证码就能登录或恢复。如果有不使用密码或移除短信的设置，就开启它。把恢复码存放在别处，例如密码管理器中。
如果你在开发服务，检查域名验证和恢复流程
实现 passkey（WebAuthn）时，在服务器端验证签名是否限定于你的域名（RP ID）和来源（origin）。不要自己编写签名验证；使用成熟的库。另外，如果残留着只需短信的恢复路径，即使上线了 passkey，那里也会成为弱点。
出处（一手资料）
- FIDO Alliance，“Passkeys” — fidoalliance.org（定义、同步与设备绑定 passkey、抗钓鱼）
- W3C，“Web Authentication: An API for accessing Public Key Credentials Level 3” — w3.org（凭据限定于 RP ID 和 origin）
- NIST SP 800-63B-4，“Digital Identity Guidelines: Authentication and Authenticator Management”（2025 年 7 月） — pages.nist.gov（同步 passkey 在 AAL2 允许、在 AAL3 不允许，何为抗钓鱼，生物识别在设备上比对）
- 日本证券业协会，关于防止网上交易未授权访问的指南修订（2025 年 10 月 15 日，日文） — jsda.or.jp（PDF）
- 日本金融厅，关于网上证券服务未授权访问和交易的提醒（日文） — fsa.go.jp
- passkeys.dev（面向实现 passkey 的开发者的指南） — passkeys.dev
接下来阅读
- 入门：如何挑选密码管理器（也关系到 passkey 的保管・同步）
- 两步：如何挑选多因素认证（MFA）（什么是抗钓鱼） / 设置 GitHub 双因素认证（把 passkey 添加为备用）
- 原理：密码的安全保存方法 / 术语：什么是钓鱼
- 术语：什么是双因素认证 / 什么是一次性密码（OTP）（与 passkey 作比较的方式）