从2026年9月1日起,微软开始将passkeys作为Entra ID的默认登录方式,而从2027年2月1日起,将停止提供SMS和语音验证码。谷歌在2023年10月就将访问密钥作为个人账户的主要登录选项。对于一个人来说,使用一个账户非常方便。但对于那些在反检测环境中管理多个账户的人来说,passkey很容易成为连接孤立个人资料的隐形纽带。下面我们将探讨这一过程是如何发生的,以及如何构建一个密钥不会在账户之间“泄露”的方案。
为什么这个问题现在被提上日程
Passkeys自2022年以来就存在,但到2026年,它们从“可以启用”变成了“将被要求”。有三个具体原因:
- 微软Entra ID。 从2026年9月起,确认通过SMS或电话登录的用户将自动启用passkeys:在下次MFA验证时,会出现注册密钥的提示。在2027年1月31日之前可以推迟,但从2027年2月1日起将无法推迟。微软引用的理由是:使用AI的网络钓鱼活动获得54%的点击率,而普通活动只有12%。
- 谷歌。 从2023年10月起,个人账户默认启用了“在可能的情况下跳过输入密码”选项。如果密钥已创建,谷歌会建议使用该密钥登录。
- 在管理器之间转移密钥。 FIDO联盟发布了凭证交换标准(CXF和CXP格式)。在iOS 26和macOS 26中,可以在Apple Passwords、1Password、Bitwarden、Dashlane等应用之间加密传输passkeys,而无需导出文件。密钥不再死死绑定于一个存储。对于多账户管理来说,这既是机会,也是风险。
passkey的工作原理及其如何打破个人资料的隔离
Passkey是一对加密密钥。公钥由网站存储,私钥由“身份验证器”存储。密钥与域名绑定(在规范中称为rpId),因此钓鱼网站无法获取它。多账户管理的主要问题是私钥物理存储在哪里。反检测环境隔离cookies、localStorage、IndexedDB和指纹。密钥存储通常位于浏览器配置外:
- Windows Hello在Windows账户级别存储密钥。任何浏览器和该账户下的任何配置都访问同一个存储。
- macOS上的iCloud密钥链属于Apple ID。Chrome和Safari在同一台Mac上看到同一组密钥。
- 谷歌密码管理器与登录浏览器或手机的谷歌账户绑定。一个服务性的谷歌账户可以在二十个配置中共享一个保险箱。
- 扩展管理器(Bitwarden、1Password等)在其账户存储中保存密钥。一个存储对所有配置起作用,成为一个可见的单一接入点。
由此产生的典型故障是:您在账户编号为7的配置中点击“使用访问密钥登录”,系统却显示账户编号为3和12的密钥在同一网站上。该网站无法看到这个列表:它只接收所选的密钥。但一次错误的点击——账户编号3就会从配置中登录,使用账户编号7的IP和指纹。这种联系是无法撤销的。
网站在使用passkey登录时实际了解什么
Passkey并没有消除风险评分,它只是替代了密码。在登录时,平台仍然可以看到IP、浏览器指纹和会话历史。此外,还会收到一些WebAuthn的信号:
- 密钥标识符(credential ID)。它对“账户—身份验证器”这一对是唯一的。
- AAGUID——身份验证器的模型标识符。网站如谷歌会根据此标识符在账户设置中签署密钥:“在iCloud密钥链中创建”、“在谷歌密码管理器中”等等。这不是您设备的唯一编号,但这是另一个特征,必须与个人资料的传说相符。
- BE和BS标志(备份资格和备份状态)显示该密钥是同步的还是绑定到设备的。
结论是:“移动”个人资料使用Windows Hello的密钥登录,看起来与来自德国的IP和巴西时区的iPhone同样不合逻辑。密钥必须与代理和指纹保持一致。
逐步方案:一个账户——一个配置——一个存储——一个IP
- 进行清点。 列出您的账户已经拥有passkeys或出现创建建议的平台:谷歌、微软、大型市场和社交网络。在每个账户的安全设置中,可以看到注册了多少密钥以及它们的创建位置。所有意外的“Windows Hello”和“iCloud密钥链”记录都是删除的候选者。
- 为工作配置禁用系统密钥存储。 在使用配置的浏览器中,关闭内置管理器的密码和访问密钥保存功能。在工作机器上不要在Windows Hello或iCloud密钥链中创建密钥。如果创建密钥的窗口提示“此计算机”,请选择其他方式。
- 为每个账户选择存储。 规则很简单:存储必须与配置一样分开。选项:
- 每个账户或同一客户的一组账户的单独密码管理器存储;
- 为少数最有价值的账户使用硬件密钥(FIDO2);
- 用于自动化——软件身份验证器,关于它将在第6步中介绍。
- 仅从“原生”配置注册密钥。 相同的配置、相同的指纹、相同的代理与固定会话、相同的地理位置,正如账户正常工作时一样。注册密钥是一个敏感操作,平台对此非常关注。过程中的IP更改通常会导致额外的验证。我们在文章中详细讨论了如何为配置保持一个地址 sticky会话或代理轮换。
- 保留备用登录方式。 丢失的存储意味着丢失账户。每个账户需要第二种登录方式:在另一个存储中的第二个passkey、带有TOTP的密码或与密钥分开存储的恢复代码。微软在Entra中明确要求在2027年2月之前将用户转移到防钓鱼方法。不要等到注册窗口停止关闭。
- 在自动化中使用虚拟身份验证器。 在Chrome DevTools协议中有WebAuthn域。方法
addVirtualAuthenticator创建一个具有ctap2协议和internal(平台)或usb/hybrid传输的程序身份验证器。参数hasResidentKey和hasUserVerification包括在身份验证器上存储密钥和用户验证。getCredentials在注册后返回整个密钥:credentialId、rpId、userHandle、signCount和PKCS#8格式的私钥。addCredential在下次启动时将其放回。这样就得到了一个仅在您的秘密存储中存在并连接到特定账户会话的密钥。有两个注意事项:域被标记为实验性,并为测试WebAuthn而创建,而导出的私钥是密码级别的秘密,必须相应存储。 - 通过凭证交换转移密钥,而不是手动转移。 如果您更换管理器或将账户分散到不同的存储中,请使用FIDO标准的内置导出:它在Apple Passwords、1Password、Bitwarden、Dashlane、DuckDuckGo、Devolutions中受支持。请注意,在macOS上,部分应用尚未实施此机制。
潜在问题
- 默认同步。 在“此设备上”创建的密钥可能立即上传到iCloud或谷歌云,并出现在该账户的所有设备上,包括您的个人手机。
- 通过QR码的跨设备登录。 “用手机扫描QR码”的场景(混合传输)将真实手机与其密钥连接到配置会话。对于工作配置来说,这是额外的联系。
- 整个农场的AAGUID相同是正常的。 数百万人使用同一个管理器。危险的不是相同的提供商,而是共同的密钥或共同的存储。
- Passkey并不能解决“脏”登录问题。 如果账户使用的IP已经在邻近账户上曝光,或者来自平台不喜欢的数据中心,强大的加密也无济于事。风险是根据信号的综合评估。
- 第二因素也需要隔离。 如果备用登录方式是TOTP,秘密也会分散到各个账户,而不是存放在个人手机上的一个应用中。我们在材料中讨论了如何将2FA与代理结合起来 关于通过代理的双因素身份验证。
需要什么样的代理以及原因
对于使用密钥登录来说,最重要的是一致性:账户必须在同一网络、同一地理位置注册密钥并进行登录。因此:
- 反检测中的网络配置—— 住宅代理,在账户所在国家/地区保持固定会话。这是家庭提供商的地址,符合“普通用户在家”的传说。
- 移动平台和具有移动传说的账户—— 移动代理。在国家另一端的家庭网络上注册密钥的移动配置,打破了其历史。
- 每次请求轮换适合解析,但不适合登录账户。请为整个工作会话设置足够的间隔。
结论
Passkeys使登录抵御钓鱼攻击,但将账户之间的连接点从cookies和密码转移到了密钥存储。这一连接点通常位于反检测配置之外:在Windows Hello、iCloud、谷歌账户或管理器的公共存储中。工作方案如下:每个账户有自己的配置、自己的密钥存储、自己的固定IP和备用登录方式。对于自动化,CDP中有虚拟身份验证器。在2027年2月之前处理此事,届时微软将停止允许推迟注册。之后,您将不得不在紧急情况下直接处理真实账户。
