「认证本该像解锁手机一样自然。」这是我对通行密钥（passkey）最初的期待。但当我真的把主密码全删掉、全靠设备验证时，才发现生态系统的裂缝比想象中深。
理想场景：单设备上的丝滑体验
在主力机上启用通行密钥的过程确实干净。打开账户设置，选择选项，验证身份，系统存好凭证——没有字符串要保存，没有密码管理器要打开。解锁即登录，认证流程退到了后台。
这部分体验符合承诺：不打扰、不记忆、不管理。问题从第二台设备开始。
裂缝一：同步机制成了黑箱
通行密钥依赖公钥加密，私钥留在设备本地。但多设备场景下，「密钥怎么流转」各家做法不一。
苹果的通行密钥走iCloud钥匙串，谷歌用Google密码管理器，微软押注Windows Hello。三家云不同步，跨生态登录时，你会发现某些账户的通行密钥只存在于某一台设备。
更隐蔽的问题是恢复场景。手机丢了怎么办？厂商的恢复流程设计参差不齐——有的要求备用邮箱+短信验证，有的强制等待期，有的干脆让你重新注册。这些 fallback 路径的存在，说明无密码架构并未真正摆脱「备用凭证」的依赖。
裂缝二：服务端的密码假设
我遇到最频繁的摩擦不是技术故障，而是流程设计。
大量服务在「添加通行密钥」后，仍然强制保留密码作为登录选项。部分平台甚至把通行密钥设为「备用方式」，主路径仍是密码框。这导致一个悖论：你越想用通行密钥减少攻击面，越发现密码这条后门始终敞着。
更深层的矛盾在于账户恢复。当我尝试在某云服务关闭密码登录、仅保留通行密钥时，系统提示「需要至少一种备用认证方式」——而可选列表里，短信、邮箱、恢复码本质上都是密码体系的变体。
生态尚未准备好让密码真正退场。
裂缝三：跨平台的工作流断裂
开发者和运维场景暴露了更硬的边界。
在Linux工作站登录云服务、用备用安卓机访问银行应用、通过浏览器扩展管理基础设施——这些场景下，通行密钥的「设备绑定」特性成了阻碍。没有统一的标准让密钥在不同生态间可信迁移，用户被迫在「便利性」和「安全性」之间做非此即彼的选择。
部分服务尝试用二维码跨设备授权，但流程比直接输密码慢三倍。当效率损失累积，很多人会悄悄把密码重新存进管理器。
正方：通行密钥确实解决了一些真问题
钓鱼攻击在通行密钥架构下几乎失效——没有可窃取的密码字符串，中间人无法重放凭证。这对高价值账户（邮箱、金融、开发者平台）是实质性改进。
单设备体验的无摩擦感，也确实降低了普通用户的安全门槛。不再有人因为「记不住复杂密码」而重复使用123456。
从架构视角，私钥不出设备的设计符合「最小权限」原则。即使服务商数据库泄露，攻击者拿到的公钥无法用于登录。
反方：当前部署方式制造了新的碎片化
但「降低用户认知负担」的承诺，在多设备场景下被抵消了。用户现在需要理解：苹果钥匙串、谷歌密码管理器、第三方硬件密钥、平台原生方案——这些互不兼容的选项，哪个存着我的凭证？
同步的不确定性带来焦虑。当我无法确定备用手机能否登录某个账户时，我会本能地保留密码作为保险。这种「双轨制」反而扩大了攻击面，而非缩小。
更关键的是，通行密钥没有解决身份恢复这个终极难题。它只是把「忘记密码」换成了「丢失设备」，而后者的社会工程攻击向量同样丰富。
判断：过渡期的结构性矛盾
通行密钥的困境不是技术失败，而是生态位错配。
它假设了一个「苹果/谷歌/微软三足鼎立、各自闭环」的世界，但真实的工作流是跨平台的、临时的、设备频繁更替的。当标准制定者（FIDO联盟）与平台巨头（掌握实际分发渠道）的利益不完全一致，用户体验的裂缝就难以弥合。
我的判断是：通行密钥会在「高安全需求、单设备主导」的场景先落地——企业SSO、iPhone用户的苹果生态账户、硬件密钥绑定的开发者账号。但「彻底无密码」的愿景，需要等跨平台同步协议成熟、服务端真正敢关掉密码 fallback 之后。
在此之前，多数人的最优策略可能是「混合态」：核心账户用通行密钥+硬件密钥双保险，边缘服务保留密码管理器，接受一定程度的碎片化。
这件事的真正价值
通行密钥实验暴露了一个被忽视的命题：认证技术的演进速度，从来不取决于密码学强度，而取决于「账户恢复」的社会工程复杂度。
我们可以造出不可破解的密钥，但无法造出不会丢手机的人类。只要「找回账户」仍是刚需，备用凭证链就会存在——问题只是把它藏得多深。
通行密钥的意义，或许不在于消灭密码，而在于逼行业正视一个事实：身份验证的终点不是技术方案，而是信任网络的重建。平台、设备、用户、恢复代理之间的权责边界，需要比加密算法更精细的设计。
当你下次看到「支持通行密钥」的按钮时，值得问的是：这家服务商有没有勇气，真的让你删掉密码？还是只是多贴了一层安全感的包装？
热门跟贴