WebAuthn 指纹识别：FIDO2 API 如何暴露你的身份

简介

WebAuthn（Web 认证）是一个 W3C 标准，使用公钥加密实现无密码认证。它允许用户使用生物识别传感器、安全密钥或设备内置的平台认证器登录网站。该 API 支持 passkeys、FIDO2 安全密钥以及现代网站上越来越常见的生物识别登录提示。

WebAuthn 是 Web 安全的重大改进，用抗网络钓鱼的加密凭据替换密码。然而，该 API 也暴露了设备认证能力的信息。这些能力信号因平台、硬件和浏览器版本而异，且可以在无需用户交互或权限的情况下静默查询。这使得 WebAuthn 成为大多数用户完全不知道的微妙但有效的指纹向量。

随着 passkeys 成为密码的标准替代品，WebAuthn 查询将在 Web 上变得更加常见。保护 WebAuthn 信号是全面指纹保护日益重要的方面。

隐私影响

WebAuthn 能力指纹识别微妙但有效。这些信号不需要用户交互或权限。网站可以在任何登录流程开始之前静默查询认证器可用性，并使用响应构建设备配置文件。这在后台发生，对用户没有任何可见指示。

隐私问题包括：

• 平台识别：能力查询揭示设备是否具有生物识别硬件或安全芯片。具有 Touch ID、Windows Hello、指纹传感器的设备和没有任何生物识别硬件的设备都产生不同的响应。这立即将用户分成硬件类别并缩小其平台身份。

• 浏览器版本检测：某些 WebAuthn 功能在特定浏览器版本中添加。这些功能的存在和行为揭示浏览器的版本范围，即使在 User-Agent 字符串精简努力使 User-Agent 头信息更少之后。

• Headless 浏览器检测：标准 headless Chrome 环境通常报告没有可用的平台认证器，因为 headless 上下文中没有安全硬件。这是用于识别自动化环境的信号之一。

• 功能支持矩阵：认证器可用性、条件调解支持和其他功能支持的组合创建了一个因平台而异的矩阵。不同的操作系统和硬件配置产生不同的功能组合，增加了整体指纹。

2023 年的一项研究检查了 Alexa 排名前 50,000 的网站中 WebAuthn 的部署，发现超过 20% 的网站查询了 WebAuthn 能力，即使它们不提供基于 WebAuthn 的登录。这表明能力查询被用于认证之外的目的，可能包括指纹识别和环境分析。

为什么这对你的隐私很重要

静默数据收集

WebAuthn 能力查询完全静默。没有权限提示，没有通知徽章，没有任何形式的视觉指示。任何网站在你访问时就可以确定你设备的认证能力，甚至在你与页面上的任何内容交互之前。这种静默收集是 WebAuthn 指纹识别特别令人担忧的原因。

硬件分析

你设备的认证能力与其硬件绑定。你是否有生物识别传感器，有什么类型的安全硬件，你的设备支持什么认证方法，这些都通过 WebAuthn 查询揭示。这个硬件配置文件是持久的：当你清除 Cookie、切换到隐身模式或使用不同的浏览器配置文件时，它不会改变。

Passkey 未来

行业正在迅速向 passkeys 作为密码替代品迈进。这意味着 WebAuthn 能力查询将在 Web 上变得更加常见。目前偶尔出现的指纹信号将成为大多数网站上的常规查询，使 WebAuthn 保护对重视隐私的人越来越重要。

Headless 环境检测

对于隐私研究人员、自动化测试工程师以及任何运行浏览器自动化的人来说，WebAuthn 信号提出了特定的挑战。标准 headless 环境缺少安全硬件，产生与正常桌面浏览器不同的能力响应。这种差异可以识别自动化环境，影响隐私研究的有效性和自动化工作流程的可靠性。

常见保护方法及其局限性

VPN 和代理服务器

VPN 对 WebAuthn 能力信号没有影响。认证器可用性是本地硬件属性，与网络路由无关。同一 VPN 后面的两台设备根据其本地硬件报告完全不同的 WebAuthn 能力。VPN 保护你的网络身份，但让你的硬件指纹完全暴露。

隐身和隐私浏览

隐私浏览模式不改变 WebAuthn 能力响应。平台认证器可用性在隐身和正常窗口中相同，因为 API 查询的是硬件能力，而非存储的数据。隐身模式设计用于防止 Cookie 和历史记录持久化，而非修改硬件级能力报告。

浏览器扩展

扩展在 WebAuthn 保护方面面临根本限制：

• 检测面：在 JavaScript 级别覆盖能力查询方法会改变其内部属性，可通过检查技术检测。
• 功能影响：错误地报告平台认证器可用性会在网站尝试发起依赖报告能力的认证流程时导致问题。
• 范围限制：扩展无法控制浏览器如何处理凭据创建和检索调用。

禁用 WebAuthn

完全禁用 WebAuthn（从浏览器中移除 API）本身是一个强信号。随着 passkeys 变得更加普遍，缺少 WebAuthn 支持在现代浏览器中越来越罕见，标记环境为不寻常。

BotBrowser 的引擎级方法

BotBrowser 通过其配置文件系统在浏览器引擎级别控制 WebAuthn 能力信号。所有与认证器相关的查询返回与加载配置文件目标平台一致的结果。这不是 JavaScript 覆盖或浏览器扩展。BotBrowser 修改浏览器的内部认证器能力报告，因此原生 API 本身产生配置文件一致的结果。

基于配置文件的认证器配置

chrome --bot-profile="/path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

配置文件定义了完整的 WebAuthn 能力集：平台认证器可用性、条件调解支持、支持的传输方法、算法支持和功能可用性。所有值从真实设备捕获，确保内部一致性。

跨平台一致性

在 Linux 服务器上运行 macOS 配置文件展示了引擎级控制的力量。没有 BotBrowser，Linux 服务器报告没有平台认证器。加载 macOS 配置文件后，能力查询报告平台认证器可用，与配置了生物识别认证的 Mac 一致。

这种跨平台对齐扩展到所有 WebAuthn 信号：

• 平台认证器可用性匹配配置文件的操作系统和硬件配置
• 条件调解支持匹配配置文件的浏览器版本
• 传输类型支持匹配配置文件的平台
• 功能可用性匹配配置文件的认证器能力

BotBrowser 确保每个 WebAuthn 信号与浏览器配置文件的其余部分讲述同样的故事，创建连贯且真实的身份。

Headed 和 Headless 一致性

BotBrowser 在 headed 和 headless 模式下保持一致的 WebAuthn 行为。配置文件的值无论显示模式如何都被应用，消除了 headless 浏览器报告与 headed 不同认证器能力的常见情况。

# Headless 模式具有完整 WebAuthn 信号
chrome --bot-profile="/path/to/profile.enc" \
       --headless \
       --user-data-dir="$(mktemp -d)"

无论你在桌面还是 headless 服务器上运行 BotBrowser，你的 WebAuthn 信号都是相同的。这对于隐私研究、自动化测试以及任何需要跨不同执行环境保持一致指纹身份的工作流程至关重要。

完整的能力响应

BotBrowser 的配置文件不仅仅是设置布尔标志。它们配置完整的 WebAuthn 行为矩阵，包括支持的加密算法、传输可用性和偏好排序、驻留密钥和用户验证处理，以及功能支持和响应格式。所有这些细节都匹配配置文件的目标平台和浏览器版本，创建全面且真实的 WebAuthn 身份。

配置和使用

基本 CLI 用法

加载配置文件时自动提供 WebAuthn 保护：

chrome --bot-profile="/path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

Playwright 集成

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: ['--bot-profile=/path/to/profile.enc'],
    headless: true,
  });

  const context = await browser.newContext({ viewport: null });
  const page = await context.newPage();

  const webauthnInfo = await page.evaluate(async () => {
    const results = {};
    if (window.PublicKeyCredential) {
      results.available = true;
      results.platformAuth = await PublicKeyCredential
        .isUserVerifyingPlatformAuthenticatorAvailable();
      if (PublicKeyCredential.isConditionalMediationAvailable) {
        results.conditionalUI = await PublicKeyCredential
          .isConditionalMediationAvailable();
      } else {
        results.conditionalUI = 'not supported';
      }
    } else {
      results.available = false;
    }
    return results;
  });

  console.log('WebAuthn signals:', webauthnInfo);
  await browser.close();
})();

Puppeteer 集成

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: ['--bot-profile=/path/to/profile.enc'],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('about:blank');

  const authInfo = await page.evaluate(async () => ({
    publicKeyCredential: !!window.PublicKeyCredential,
    platformAuth: window.PublicKeyCredential
      ? await PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()
      : false,
  }));

  console.log('Authenticator info:', authInfo);
  await browser.close();
})();

与完整配置文件结合

为获得全面的身份一致性，将 WebAuthn 保护与其他 BotBrowser 功能结合：

chrome --bot-profile="/path/to/profile.enc" \
       --bot-noise-seed=42 \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-config-timezone="America/Los_Angeles" \
       --bot-config-locale="en-US" \
       --user-data-dir="$(mktemp -d)"

此配置提供一个完整、连贯的身份，其中每个信号（从 WebAuthn 能力到时区、区域和网络身份）都讲述一致的故事。

验证

使用配置文件启动 BotBrowser 后，验证 WebAuthn 信号是否正确保护：

1. 平台认证器可用性返回与配置文件平台一致的值。macOS 带生物识别硬件的配置文件应报告可用，Linux 桌面配置文件通常应报告不可用。

2. 条件调解支持匹配配置文件浏览器版本能力。

3. Headless 和 headed 一致性得到维护。在两种模式下运行相同查询并确认结果相同。

4. 跨配置文件差异化存在。不同平台配置文件应产生不同的 WebAuthn 响应。

5. 指纹测试工具显示 WebAuthn 信号和其他平台指标之间没有不一致。你的 WebAuthn 身份应与你的平台、User-Agent 和 navigator 属性对齐。

你可以使用指纹测试网站或 BotBrowser 的内置验证工具来确认这些信号正确对齐。

最佳实践

1. 使用平台适当的配置文件。 macOS 配置文件应报告生物识别认证器可用性。Linux 桌面配置文件通常应报告不可用。BotBrowser 配置文件从真实设备捕获，因此当你为你的需求选择正确的配置文件时，这种对齐是内置的。

2. 验证 headless 行为。 如果在 headless 模式下运行，确认 WebAuthn 信号匹配相同配置文件的 headed 模式行为。这种一致性是 BotBrowser 对运行 headless 工作流程的人的关键优势之一。

3. 考虑 passkey 生态系统。 随着 passkeys 变得更普遍，WebAuthn 能力查询将更常见。确保配置文件包含现代浏览器版本的适当条件调解支持。使用最新的配置文件是保持领先于这一趋势的最佳方式。

4. 与其他平台信号对齐。 WebAuthn 可用性应与配置文件中的 navigator 属性、User-Agent 和其他操作系统特定信号一致。BotBrowser 配置文件自动确保这种对齐，但验证可以给你信心确认一切正常工作。

5. 与全面保护结合。 WebAuthn 是众多指纹向量之一。为获得完整保护，使用覆盖所有指纹面的完整 BotBrowser 配置文件，从 WebAuthn 到 Canvas、音频、WebGL 等。有关选择和管理配置文件的详细信息，请参阅配置文件管理指南。

常见问题

WebAuthn 指纹识别在无用户交互的情况下工作吗？

是的。能力查询是被动查询，不需要用户交互、权限，也不产生提示。任何网站都可以静默且即时地确定你设备的认证能力。这就是为什么通过 BotBrowser 进行主动保护至关重要。

网站能检测到 WebAuthn 信号被控制了吗？

如果控制在 JavaScript 级别应用（覆盖原生方法），可以通过检查技术检测。BotBrowser 在引擎级别应用控制，因此原生方法本身返回受控值，没有任何 JavaScript 修改可检测。保护对网站完全不可见。

BotBrowser 支持实际的 WebAuthn 认证流程吗？

BotBrowser 的 WebAuthn 保护关注能力信号，即网站用于指纹识别和环境分析的被动查询。实际认证流程（创建凭据、签名挑战）需要真实的认证器交互，这是与指纹保护不同的关注点。BotBrowser 保护你的指纹身份，同时保持认证基础设施完整。

这与 passkeys 有什么关系？

Passkeys 使用 WebAuthn API。BotBrowser 控制的能力信号（平台认证器可用性、条件调解支持）与 passkey 实现查询的相同信号。控制这些信号确保无论主机环境如何都有一致的报告。随着 passkeys 变得更常见，这种保护变得更加重要。

WebAuthn 信号在 Chrome 版本间不同吗？

是的。某些功能在特定 Chrome 版本中引入。较旧的 Chrome 版本不公开这些功能。BotBrowser 配置文件有版本控制，包含目标浏览器版本的适当 WebAuthn 功能集，确保你的信号匹配有效的真实世界配置。

navigator.credentials 怎么处理？

navigator.credentials API 比 WebAuthn 更广泛，也包含密码凭据和联合凭据。BotBrowser 配置文件控制与指纹识别相关的公钥凭据特定能力。密码和联合凭据管理行为受配置文件和用户数据目录影响。

这是否保护免受基于认证的指纹识别？

认证（attestation）是凭据创建流程中认证器提供关于其身份的签名声明的功能。BotBrowser 的能力信号保护解决的是被动指纹识别，这是主要的追踪问题。基于认证的识别发生在活跃的认证流程中，需要用户交互。

headless 环境能单独通过 WebAuthn 被识别吗？

使用标准 headless Chrome 时，是的。headless 模式下缺少平台认证器产生与正常桌面浏览器不同的响应。BotBrowser 通过在 headed 和 headless 模式下保持配置文件一致的 WebAuthn 信号消除了这一点，因此你的 headless 环境与普通桌面浏览器无法区分。

总结

WebAuthn 能力信号揭示平台、硬件和浏览器版本信息，作为持久的指纹向量。平台认证器可用性、条件调解支持和更广泛的功能矩阵因设备和操作系统而异，创建不需要用户交互的独特信号。随着 passkeys 成为 Web 认证的标准，这些查询只会变得更常见。BotBrowser 通过其配置文件系统在引擎级别控制所有 WebAuthn 信号，确保跨平台和 headed/headless 一致性。相关保护请参阅 Navigator 属性保护、自动化检测防护和全面配置文件管理。