- Published on
我不喜欢通行密钥:个人安全视角下的隐忧
- Authors
- Name
- ethanhawksley
- hawksley.dev

通行密钥的承诺与现实
近年来,科技行业持续将通行密钥(Passkeys)吹捧为终极登录解决方案。许多大型科技公司在用户每次登录时都会“贴心”地告知通行密钥有多么便捷和省力。用户要么妥协并设置通行密钥,要么深入设置寻找关闭选项。谷歌甚至将相关设置命名为“尽可能跳过密码”,微软则宣传用户应使账户无密码化。
通行密钥本身是一项出色的技术。由于它们与创建时绑定的网站一一对应,黑客无法通过伪造的登录界面进行钓鱼攻击。即使网站遭遇数据泄露,通行密钥的非对称特性也使得攻击者无法从服务器端数据中恢复密钥。这使得通行密钥非常适合企业环境,但对个人安全而言却并不理想。
对个人用户来说,最大的风险反而是账户永久锁定、自动账户封禁以及设备丢失。使用通行密钥,用户能更好地防御中间人攻击,但同时也面临着更高概率的账户访问丢失风险。通行密钥消除了标准登录流程中的钓鱼攻击,却营造了一种虚假的安全感。账户的安全性仍然取决于最薄弱的恢复方法:短信、电子邮件链接、安全问题等。如果这些恢复方法未启用,用户就面临永久锁定的风险。
硬件密钥的局限
根据设计,用户无法在硬件密钥上创建通行密钥的备份:通行密钥只能添加或删除,无法移动。因此,用户需要购买2到3个硬件密钥,并为每个网站注册每一个密钥。这很快就会变得昂贵,并且随着账户数量的增加,扩展性很差。
硬件密钥支持可发现凭据,网站可以查询用户名而无需用户手动输入。这种功能在网站开发者中越来越受欢迎,但每个硬件密钥的容量限制为25到100个账户,顶级密钥最多也只能存储300个。一旦超出限制,用户必须删除一些账户,或者购买另一套硬件密钥。
同步通行密钥的平台锁定
苹果和谷歌都希望用户的身份锚定在其操作系统上。它们设备上的“快乐路径”是使用与苹果或谷歌账户绑定的同步通行密钥管理。如果这些自动化系统某天决定封禁用户的账户,用户将不可逆地失去对所有第三方账户中通行密钥的访问权限。
FIDO联盟一直在努力改善互操作性,使通行密钥的导出更加容易,但不同提供商之间的体验仍然碎片化且不一致。这种情况在未来几年有望改善,但目前还不够成熟,无法依赖。相比之下,密码只是一个字符串,必要时可以轻松手动导出。
第三方同步通行密钥的困境
当用户将通行密钥存储在Bitwarden或KeePassXC等密码管理器中时,往往会与平台发生冲突。尽管操作系统最近引入了供第三方工具接入的API(如Android的凭据管理器),但体验仍然碎片化,缺乏密码自动填充数十年积累的UX打磨。浏览器之外和原生应用内的自动填充尤其不一致。
作者认为,未来第三方通行密钥将是发展方向,但目前尚未达到理想状态。
通行密钥失效的场景
在用户自己的设备上登录账户是通行密钥的理想场景。但当用户需要操作同事的电脑时,情况就变得非常不便。用户可能插入硬件密钥,但并非总能访问端口。用户也可以登录并使用同步通行密钥,但这需要信任该电脑不会泄露所有其他通行密钥。最后一种选择是使用“混合传输”,即扫描二维码并通过蓝牙同时连接到电脑。虽然这种方案在理论上安全且可行,但现实中充满了连接失败或蓝牙完全不支持的边缘情况。
通行密钥尚未成熟
作者认为,企业用户有充分的理由使用通行密钥,但整个生态系统对个人用户来说还不够成熟。虽然TOTP验证码存在已知的钓鱼漏洞,但通行密钥的恢复和锁定风险对大多数人构成的日常风险比中间人攻击代理更大。
将随机生成的密码存储在第三方密码管理器中,并配合独立的TOTP应用,既能赋予用户控制权,又不失纯文本的灵活性。对于之前在所有网站上重复使用密码的用户来说,通行密钥是一个巨大的进步。但对于其他所有人来说,它目前是一种倒退。
原标题:I don't like passkeys。 HN 原始发布时间:2026年9月18日星期五。当前记录为 740 分、718 条评论。