Huella digital

Huella digital WebAuthn: cómo las APIs FIDO2 exponen tu identidad

Cómo las capacidades de autenticadores WebAuthn y FIDO2 se convierten en vectores de huella digital, y técnicas para controlar las señales de autenticación.

Documentación

Quieres la documentación estructurada de Huella digital?

Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.

Introducción

WebAuthn (Web Authentication) es un estándar del W3C que permite la autenticación sin contraseña usando criptografía de clave pública. Permite a los usuarios iniciar sesión en sitios web usando sensores biométricos, llaves de seguridad o autenticadores de plataforma integrados en sus dispositivos. La API habilita las passkeys, llaves de seguridad FIDO2 y las solicitudes de inicio de sesión biométrico que se han vuelto cada vez más comunes en sitios web modernos.

WebAuthn es una mejora significativa para la seguridad web, reemplazando las contraseñas con credenciales criptográficas resistentes al phishing. Sin embargo, la API también expone información sobre las capacidades de autenticación del dispositivo. Estas señales de capacidad varían según la plataforma, el hardware y la versión del navegador, y pueden consultarse silenciosamente sin interacción o permiso del usuario. Esto hace de WebAuthn un vector de huella digital sutil pero efectivo del que la mayoría de los usuarios desconocen por completo.

A medida que las passkeys se convierten en el reemplazo estándar de las contraseñas, las consultas WebAuthn serán aún más comunes en la web. Proteger tus señales WebAuthn es un aspecto cada vez más importante de la protección integral de huella digital.

Impacto en la privacidad

La huella digital por capacidades WebAuthn es sutil pero efectiva. Las señales no requieren interacción ni permiso del usuario. Un sitio web puede consultar la disponibilidad del autenticador silenciosamente, antes de que comience cualquier flujo de inicio de sesión, y usar las respuestas para construir un perfil del dispositivo. Esto ocurre en segundo plano sin ninguna indicación visible para el usuario.

Las preocupaciones de privacidad incluyen:

  • Identificación de plataforma: Las consultas de capacidad revelan si un dispositivo tiene hardware biométrico o chips de seguridad. Los dispositivos con Touch ID, Windows Hello, sensores de huella digital y los que no tienen hardware biométrico producen respuestas diferentes. Esto segmenta inmediatamente a los usuarios en categorías de hardware y reduce su identidad de plataforma.

  • Detección de versión del navegador: Ciertas funciones WebAuthn fueron añadidas en versiones específicas del navegador. La presencia y comportamiento de estas funciones revelan el rango de versión del navegador, incluso después de que los esfuerzos de reducción de la cadena User-Agent hayan hecho el encabezado User-Agent menos informativo.

  • Detección de navegador headless: Los entornos estándar de Chrome headless típicamente reportan que no hay autenticador de plataforma disponible, porque no hay hardware de seguridad en un contexto headless. Esta es una de las señales usadas para identificar entornos automatizados, lo cual importa para la investigación de privacidad y los flujos de trabajo de pruebas automatizadas.

  • Matriz de soporte de funciones: La combinación de disponibilidad del autenticador, soporte de mediación condicional y otro soporte de funciones crea una matriz que varía según la plataforma. Diferentes sistemas operativos y configuraciones de hardware producen combinaciones de funciones distintas, añadiendo a la huella digital general.

Un estudio de 2023 que examinó el despliegue de WebAuthn en los 50,000 sitios principales de Alexa encontró que más del 20% de los sitios consultaban las capacidades WebAuthn incluso cuando no ofrecían inicio de sesión basado en WebAuthn. Esto sugiere que las consultas de capacidad se están usando para propósitos más allá de la autenticación, potencialmente incluyendo huella digital y perfilado del entorno.

Por qué esto importa para tu privacidad

Recopilación silenciosa de datos

Las consultas de capacidad WebAuthn son completamente silenciosas. No hay solicitud de permisos, ni insignia de notificación, ni indicador visual de ningún tipo. Cualquier sitio web puede determinar las capacidades de autenticación de tu dispositivo en el momento en que lo visitas, antes de que interactúes con nada en la página. Esta recopilación silenciosa es lo que hace particularmente preocupante la huella digital WebAuthn.

Perfilado de hardware

Las capacidades de autenticación de tu dispositivo están vinculadas a su hardware. Si tienes un sensor biométrico, qué tipo de hardware de seguridad está disponible y qué métodos de autenticación soporta tu dispositivo se revelan a través de consultas WebAuthn. Este perfil de hardware es persistente: no cambia cuando limpias cookies, cambias a modo incógnito o usas un perfil de navegador diferente.

El futuro de las passkeys

La industria se está moviendo rápidamente hacia las passkeys como reemplazo de contraseñas. Esto significa que las consultas de capacidad WebAuthn serán aún más comunes en la web. Lo que actualmente es una señal de huella digital ocasional se convertirá en una consulta rutinaria en la mayoría de los sitios web, haciendo que la protección WebAuthn sea cada vez más esencial para cualquiera que valore su privacidad.

Detección de entorno headless

Para investigadores de privacidad, ingenieros de pruebas automatizadas y cualquiera que ejecute automatización de navegador, las señales WebAuthn presentan un desafío específico. Los entornos headless estándar carecen de hardware de seguridad, produciendo respuestas de capacidad que difieren de los navegadores de escritorio normales. Esta diferencia puede identificar entornos automatizados, afectando la validez de la investigación de privacidad y la confiabilidad de los flujos de trabajo automatizados.

Enfoques comunes de protección y sus limitaciones

VPNs y servidores proxy

Las VPNs no tienen efecto en las señales de capacidad WebAuthn. La disponibilidad del autenticador es una propiedad local del hardware que no tiene nada que ver con el enrutamiento de red.

Modo incógnito y navegación privada

Los modos de navegación privada no alteran las respuestas de capacidad WebAuthn. La disponibilidad del autenticador de plataforma es la misma en modo incógnito que en una ventana normal, porque la API consulta capacidades de hardware, no datos almacenados.

Extensiones de navegador

Las extensiones enfrentan limitaciones fundamentales con la protección WebAuthn:

  • Superficie de detección: Anular los métodos de consulta de capacidad a nivel JavaScript cambia sus propiedades internas y es detectable a través de técnicas de inspección.
  • Impacto funcional: Reportar incorrectamente la disponibilidad del autenticador de plataforma causa problemas cuando un sitio web intenta iniciar un flujo de autenticación que depende de las capacidades reportadas.
  • Limitaciones de alcance: Las extensiones no pueden controlar cómo el navegador maneja las llamadas de creación y recuperación de credenciales, que interactúan con el framework del autenticador del sistema operativo a un nivel inferior al que las extensiones pueden alcanzar.

Deshabilitar WebAuthn

Deshabilitar WebAuthn por completo (eliminar la API del navegador) es en sí mismo una señal fuerte. A medida que las passkeys se vuelven más extendidas, la ausencia de soporte WebAuthn es cada vez más rara en navegadores modernos y marca el entorno como inusual.

El enfoque a nivel de motor de BotBrowser

BotBrowser controla las señales de capacidad WebAuthn a nivel del motor del navegador a través de su sistema de perfiles. Todas las consultas relacionadas con el autenticador devuelven resultados consistentes con la plataforma objetivo del perfil cargado. Esta no es una anulación JavaScript ni una extensión de navegador. BotBrowser modifica el reporte interno de capacidad del autenticador del navegador, de modo que las APIs nativas mismas producen resultados consistentes con el perfil.

Configuración de autenticador basada en perfil

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

El perfil define el conjunto completo de capacidades WebAuthn: disponibilidad del autenticador de plataforma, soporte de mediación condicional, métodos de transporte soportados, soporte de algoritmos y disponibilidad de funciones. Todos los valores se capturan de dispositivos reales, asegurando consistencia interna.

Consistencia multiplataforma

Ejecutar un perfil de macOS en un servidor Linux demuestra el poder del control a nivel de motor. Sin BotBrowser, un servidor Linux reporta que no hay autenticador de plataforma. Con un perfil de macOS cargado, las consultas de capacidad reportan que hay un autenticador de plataforma disponible, consistente con un Mac que tiene autenticación biométrica configurada.

Consistencia entre modo headless y con interfaz

BotBrowser mantiene un comportamiento WebAuthn consistente tanto en modo headless como con interfaz gráfica. Los valores del perfil se aplican independientemente del modo de visualización, eliminando la situación común donde los navegadores headless reportan diferentes capacidades de autenticador que los de interfaz gráfica.

# Modo headless con señales WebAuthn completas
chrome --bot-profile="/path/to/profile.enc" \
       --headless \
       --user-data-dir="$(mktemp -d)"

Configuración y uso

Uso básico por CLI

La protección WebAuthn es automática al cargar un perfil:

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

Integración con 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();
})();

Combinado con perfil completo

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)"

Verificación

  1. Disponibilidad del autenticador de plataforma devuelve un valor consistente con la plataforma del perfil.
  2. Soporte de mediación condicional coincide con las capacidades de la versión del navegador del perfil.
  3. Consistencia headless e interfaz se mantiene. Ejecuta las mismas consultas en ambos modos y confirma resultados idénticos.
  4. Diferenciación entre perfiles está presente. Diferentes perfiles de plataforma deberían producir diferentes respuestas WebAuthn.
  5. Las herramientas de prueba de huella digital no muestran inconsistencias entre señales WebAuthn y otros indicadores de plataforma.

Mejores prácticas

  1. Usa perfiles apropiados para la plataforma. Un perfil de macOS debería reportar disponibilidad del autenticador biométrico. Un perfil de escritorio Linux típicamente debería reportar no disponibilidad.

  2. Verifica el comportamiento headless. Si ejecutas en modo headless, confirma que las señales WebAuthn coincidan con el comportamiento del modo con interfaz para el mismo perfil.

  3. Considera el ecosistema de passkeys. A medida que las passkeys se vuelven más extendidas, las consultas de capacidad WebAuthn serán más comunes. Asegúrate de que tus perfiles incluyan soporte apropiado de mediación condicional para versiones modernas del navegador.

  4. Alinea con otras señales de plataforma. La disponibilidad WebAuthn debe ser consistente con las propiedades del navegador, User-Agent y otras señales específicas del SO en el perfil.

  5. Combina con protección integral. WebAuthn es uno de muchos vectores de huella digital. Para protección completa, usa un perfil BotBrowser completo que cubra todas las superficies de huella digital.

Preguntas frecuentes

¿La huella digital WebAuthn funciona sin interacción del usuario?

Sí. Las consultas de capacidad son consultas pasivas que no requieren interacción del usuario, no requieren permisos y no producen solicitudes.

¿Los sitios web pueden detectar que las señales WebAuthn están controladas?

Si el control se aplica a nivel JavaScript, puede detectarse mediante técnicas de inspección. BotBrowser aplica el control a nivel del motor, por lo que los métodos nativos mismos devuelven los valores controlados sin ninguna modificación JavaScript que detectar.

¿BotBrowser soporta flujos de autenticación WebAuthn reales?

La protección WebAuthn de BotBrowser se enfoca en las señales de capacidad, las consultas pasivas que los sitios web usan para huella digital y perfilado del entorno. Los flujos de autenticación reales (crear credenciales, firmar desafíos) requieren interacción real con el autenticador, que es una preocupación separada de la protección de huella digital.

¿Cómo se relaciona esto con las passkeys?

Las passkeys usan la API WebAuthn. Las señales de capacidad controladas por BotBrowser (disponibilidad del autenticador de plataforma, soporte de mediación condicional) son las mismas señales que consultan las implementaciones de passkeys.

¿Las señales WebAuthn difieren entre versiones de Chrome?

Sí. Ciertas funciones fueron introducidas en versiones específicas de Chrome. Los perfiles de BotBrowser tienen versiones e incluyen el conjunto de funciones WebAuthn apropiado para la versión del navegador objetivo.

Resumen

Las señales de capacidad WebAuthn revelan información de plataforma, hardware y versión del navegador que sirve como vector de huella digital persistente. La disponibilidad del autenticador de plataforma, el soporte de mediación condicional y la matriz de funciones más amplia varían según dispositivo y sistema operativo, creando una señal distintiva que no requiere interacción del usuario. A medida que las passkeys se convierten en el estándar para la autenticación web, estas consultas solo se volverán más comunes. BotBrowser controla todas las señales WebAuthn a nivel del motor a través de su sistema de perfiles, asegurando consistencia multiplataforma y entre modos headless/interfaz. Para protección relacionada, consulta protección de propiedades del navegador, prevención de detección de automatización y gestión integral de perfiles.

#Webauthn#Fido#fingerprinting#Authentication#Privacy#Passkeys

Lleva BotBrowser de la investigación a producción

Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.