账号里的Passkey是怎么登记的：新增、盘点与撤销顺序

把登录密码换成通行密钥（Passkey）之后，很多人以为账号安全的改造就完工了：没有可泄露的口令、钓鱼站骗不走认证，这确实是它相对密码的核心优势（协议层规范见WebAuthn，标准化文本为RFC 8937，W3C维护工作版本）。但登录环节的加固没有消灭账号线最古老的问题——授权登记：谁有权往这个账号里加一把新钥匙。密码时代，加验证方式要先知道密码；通行密钥时代，很多平台把新增入口做成了”在已登录设备上确认即可”，甚至是登录流程里顺带弹出的一句”要不要把这台设备设为通行密钥”。这一步的判断失误，代价比旧时代更大：密码泄露通常还能靠改密止血，而一把来路不明的通行密钥是长期有效的静默通道。本文给准备或已经启用通行密钥的用户一份登记侧清单。只谈防御，不构成投资建议。

先把协议特性讲成人话。每次通行密钥登记，都会生成一对密钥：私钥留在你确认登记的那台设备（或其绑定的安全密钥、账号密钥链）里，公钥记在账号一侧。此后每次认证，服务器发一个一次性挑战，设备用私钥签名回应——所以钓鱼站在技术上伪造不了登录，这一点常被引用。但规范同样明示了它管不到的部分：密钥的生命周期由注册管理决定，注册动作本身发生在”账号当前归你”的前提上。换句话说，通行密钥体系的安全假设是从”账号当前归你”开始的，它加固的是”验证你是谁”，没有加固”验证该不该给你加身份”。你的防线于是分两截：登录端协议替你把住了；登记端，仍然是你自己在把关。

风险场景因此和旧剧本接得上。你点开一个仿冒的登录页，它骗不走你的通行密钥，但可能把一次”新增通行密钥”的确认请求送到你已登录的账号名下——界面看起来和平台自己发起的注册引导几乎一样。你随手确认后，公钥挂进账号、私钥躺在对方控制的环境里，之后他可以从容地直接从任何入口用这把钥匙登录，全程不经过那个钓鱼页，也不触发任何”密码错误”告警。第二类场景更安静：旧设备转卖前没有做账号登出与密钥解绑、公司设备上的工作账号离职未清理——钥匙本身没被复制，但它登记过的那台设备已经不归你了。

所以真正需要建立的新习惯，是把通行密钥当作可数、可查、可删的东西来管理。具体三查。一查清单：主流平台、邮箱、云账号、交易所的安全设置页里都有通行密钥管理条目，逐平台把列出的每一条与你实际拥有和用过的设备对号——认不出的登记项，按可疑处理，先撤销再做其他。二查来源：撤销前留意登记时间与设备名，多数面板会显示创建日期和机型名称，这个元数据能区分”半年前迁移新手机时的正常登记”和”上周某晚的陌生新增”。三查兜底：通行密钥体系通常仍保留备用验证方式（恢复码、传统第二因素），逐项检查它们是否还有效——一把新钥匙被撤销后，平台要能只靠你手里的旧方式确认你的身份，否则整个体系对登记事故的纠错能力就是纸面上的。

两条边界说清楚。第一，通行密钥把被钓鱼登录变难了，但没把被社工诱导加钥匙变难：任何要求你在登录流程之外单独确认的注册请求，处理标准应当是”我此刻是否主动在设置页做这件事”，不是就停、是就核，这条纪律不因为技术换代而过期。第二，撤销一把可疑的钥匙要走正确顺序：先在本机删掉可疑设备上的登录态不解决根本问题，正确顺序始终是回到账号面板解除登记，再做设备侧清理——顺序反了，登记还在，对方还能用。登记端这一课，密码时代叫”别让人改绑”，通行密钥时代叫”别让人加锁”，本质上，它一直是同一件事。