我不喜欢通行密钥
I don't like passkeys

原始链接: https://hawksley.dev/blog/i-dont-like-passkeys

尽管大型科技公司积极推崇通行密钥(passkeys)为身份验证的未来,但其目前的实施方式更适合企业环境,而非个人使用。 通行密钥通过非对称加密有效防止了网络钓鱼,但也给个人用户带来了重大风险,最显著的就是导致永久性的账号锁定。依赖苹果或谷歌的同步通行密钥,意味着将你的整个数字身份绑定在可能随意封禁你账号的平台提供商身上。与此同时,硬件密钥虽然安全,但价格昂贵、难以扩展,且存储空间有限。 目前的生态系统十分碎片化;第三方密码管理器缺乏必要的集成完善度,而蓝牙或二维码扫描等“混合”登录方式往往不可靠。与传统密码不同——传统密码可以轻松导出、备份和迁移——通行密钥难以独立管理。 对于普通用户而言,失去账号访问权限的风险超过了防钓鱼保护带来的益处。结合稳健的第三方密码管理器和独立的 TOTP 身份验证器,依然是更优越、更灵活的解决方案。在技术成熟并实现真正的互操作性之前,通行密钥对部分人来说是一种便利,但对于追求数字安全完全掌控权的用户而言,则可能是一种倒退。

以下是讨论内容的摘要: Hacker News 社区对通行密钥(passkeys)持批评态度。他们认为,虽然通行密钥在理论上提供了防范网络钓鱼的安全性,但却带来了显著的可用性和可靠性问题。 **主要批评:** * **永久无法访问:** 批评者认为,因手机丢失、设备损坏或被大型科技公司意外封禁账号而导致失去访问权限的风险,远大于其带来的好处。与传统密码或 TOTP 不同,通行密钥在恢复或迁移时往往比较困难。 * **围墙花园:** 许多用户将通行密钥视为科技巨头(苹果、谷歌、微软)加强生态系统锁定的策略,这使得用户更难切换平台或使用独立的密码管理器。 * **用户体验不佳:** 其实现方式被描述为“不友好”。用户反映会被反复提醒设置通行密钥,登录流程复杂令人困惑,且在第三方设备或公共电脑上登录时存在困难。 * **无法委派权限:** 传统密码允许“临时委派”(例如与配偶或同事共享访问权限),而通行密钥的设计初衷则旨在禁止这种行为。 **支持者的观点:** 支持者认为,对于普通用户而言,通行密钥提供了更卓越的安全性,因为这些人通常会重复使用弱密码。他们坚持认为,在正确实现的情况下,通行密钥能提供一种“神奇的”、无需密码的体验,且比基于短信的二次验证(2FA)更安全。
相关文章

原文

For the past few years, the tech industry has kept pushing passkeys as the ultimate solution to logging in. Many Big Tech companies “helpfully” inform you every time you sign in how much easier and effortless passkeys are. The only way to make them stop is either to concede and set up a passkey or dig into the settings to find the off-switch.

Google’s Skip password when possible setting

Google goes as far as to name the setting “Skip password when possible” (opens in a new tab), and Microsoft advertises that you should make your account passwordless (opens in a new tab).

Passkeys are a fantastic technology. Since they are bound to the site they are created for, they cannot be phished by a hacker’s fake login screen. If a site suffers a data breach, passkeys are asymmetric and cannot be recovered from the server-side details.

This leads to passkeys being the perfect fit for a corporate environment, but a poor fit for personal security. To an individual, the greatest risks are instead permanent account lockout, automated account bans, and device loss. By using passkeys, you gain better security against man-in-the-middle attacks but face the higher probability scenario of losing access to your accounts.

Phishing through the standard login flow is eliminated by passkeys, but it creates a false sense of security. An account’s security is still dictated by the weakest recovery method: SMS, email links, security questions, and so on. If these recovery methods aren’t enabled, then the risk of permanent lockout remains for the user.

Hardware keys

By design, you cannot create a backup of passkeys on a hardware key: passkeys can only be added or deleted but never moved. Instead, you need to purchase 2-3 hardware keys and enroll every key for every site. This can quickly get expensive and doesn’t scale well as the number of accounts starts to grow.

Hardware keys support discoverable credentials, where websites can query for your username instead of you typing it in. These are becoming increasingly popular amongst website developers, yet have limits of 25-100 accounts (opens in a new tab)per hardware key, and top of the line keys can have up to 300. Once you exceed the limit, you must either delete some accounts or you have to buy another set of hardware keys.

Synced passkeys

Both Apple and Google want your identity anchored to their operating systems. The “happy path” on their devices is to use their synced passkey management tied to your Apple or Google account. If their automated systems decide one day to ban your account (opens in a new tab), you irreversibly lose access to all your passkeys used across all third-party accounts too.

The FIDO alliance has been working to improve interoperability and make it easier to export passkeys, but the experience is still fragmented and inconsistent across providers. This is set to improve over the coming years, but currently it is too immature to rely on. Compare with a password, which is just a string you can easily export by hand if necessary.

Third-party synced passkeys

When storing passkeys in a password manager like Bitwarden (opens in a new tab)or KeePassXC (opens in a new tab), you end up fighting the platform. Although operating systems have recently introduced APIs (like Android’s Credential Manager (opens in a new tab)) for third-party tools to hook into, the experience remains fragmented and lacks the decades of UX polish towards password autofill. Autofill outside the browser and inside native applications remains especially inconsistent. In the future, I believe third-party passkeys will be the way forward, but we are not there yet.

When passkeys don’t work

Logging into accounts on devices you own is the ideal scenario for passkeys. When you have to handle a colleague’s computer, it gets much more inconvenient. You could plug in a hardware key, but you don’t always have access to the ports. You could sign in and use a synced passkey, but that involves trusting the computer to not leak all of your other passkeys. The last option is to use “Hybrid Transport” (opens in a new tab), where you scan a QR code and connect via Bluetooth simultaneously to the computer. Whilst this option is secure and works in theory, reality is plagued with edge-cases where connections fail or Bluetooth is straight-up unsupported.

Passkeys aren’t ready yet

I believe enterprise users have good reason to use passkeys, but the ecosystem isn’t mature enough yet for individuals.

Whilst TOTP codes have known phishing vulnerabilities, the recovery and lockout risks of passkeys pose a greater day-to-day risk to most people than an AiTM proxy (opens in a new tab). A combination of randomly generated passwords stored inside a third-party password manager, paired with an independent TOTP app, gives control to the user without giving up the flexibility of plain text. For users who previously reused passwords across all their sites, passkeys are a huge step-up. For everybody else, it is currently a step back.

联系我们 contact @ memedata.com