Unit 42 revela 3 ataques a passkeys de Google en 2026

¿Qué descubrió Unit 42 sobre las passkeys de Google?

Un investigador de Unit 42, la división de inteligencia de amenazas de Palo Alto Networks, reveló tres vectores de ataque que permiten a un malware robar o suplantar passkeys sincronizadas en Google Password Manager — el sistema de autenticación sin contraseña de Google. El informe, publicado por Arie Olshtein el 3 de agosto de 2026, describe ataques que van desde la suplantación de dispositivo hasta el robo de la clave maestra que descifra todas las credenciales del usuario.

Lo que hace esta investigación particularmente relevante para founders es que no se trata de una vulnerabilidad teórica remota. Los tres ataques requieren un prerrequisito concreto: tu dispositivo ya debe estar infectado por malware. Es decir, las passkeys no son invulnerables frente a un endpoint comprometido, y eso tiene implicaciones directas para cualquier startup que gestione credenciales sensibles de sus equipos.

Los tres ataques: de incómodo a catastrófico

Olshtein bautizó estos vectores con el nombre colectivo de «Pass-ta-key», una combinación juguetona entre «passkey» y «pass the key». Cada ataque explota una suposición diferente sobre cómo funciona la seguridad de las passkeys sincronizadas:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Ataque 1 — Pass-ta-key (suplantación de dispositivo). El malware firma solicitudes de autenticación usando la clave de identidad del dispositivo TPM sin necesidad de desbloquear la pantalla, sin huella dactilar ni reconocimiento facial. Funciona porque muchos servicios web (los llamados relying parties) no validan estrictamente si la verificación biométrica realmente ocurrió. El sistema simplemente acepta la petición como válida. En pruebas del investigador, este ataque funcionó contra servicios que configuraron la verificación de usuario como «preferred» en lugar de «required».

Ataque 2 — Silver Pass-ta-key (registro de clave bajo control del atacante). Este es más sofisticado: el malware invalida la clave de verificación de usuario existente y registra una nueva generada por el atacante durante el flujo de re-registro del dispositivo. Una vez registrada la clave fraudulenta, el atacante puede iniciar sesión en las cuentas de la víctima desde su propio equipo, sin que el dispositivo de la víctima esté encendido. Esto convierte un acceso puntual en persistencia reutilizable.

Ataque 3 — Golden Pass-ta-key (robo de la clave maestra). El más grave. Olshtein descubrió que Google exponía el Security Domain Secret (SDS) — la clave maestra de 32 bytes que descifra todas las passkeys sincronizadas del usuario — en los registros de diagnóstico internos de Chrome (chrome://device-log/FIDO). Si el malware accede a esos logs, obtiene la llave que desbloquea no solo las credenciales presentes sino todas las futuras. Google retiró el SDS de los logs tras la divulgación responsable (issue 464305542), pero el investigador señala que sigue accesible en la memoria del proceso de Chrome.

La criptografía subyacente de las passkeys sigue siendo sólida. Lo que explotan son brechas entre el diseño teórico y la implementación real en servicios concretos.

Por qué esto importa para tu infraestructura

El informe es la parte 3 de una serie de investigaciones de Unit 42 sobre passkeys. La parte 1 fue publicada por CyberArk titulada «The Art of the Invisible Key», y la parte 2 analizó los mecanismos ocultos del Cloud Authenticator de Google. Esta progresión muestra que el ecosistema de autenticación passwordless está madurando rápidamente, y los atacantes están adaptándose al mismo ritmo.

Según datos citados por Malwarebytes en su cobertura del 5 de agosto de 2026, para finales de 2024 ya existían 800 millones de cuentas de Google usando passkeys. Cuando esa escala entra en juego, cualquier fallo de implementación deja de ser un problema marginal para convertirse en un riesgo sistémico.

El caso de eBay ilustra bien el punto: el servicio configuraba userVerification = required, pero el investigador demostró que aceptaba autenticaciones sin validar correctamente el flag UV (User Verified) en los datos del authenticator. Tras recibir el reporte de Unit 42, eBay corrigió la vulnerabilidad. Pero mientras tanto, cualquier cuenta protegida por passkey en eBay era potencialmente vulnerable a este ataque.

¿Qué significa esto para tu startup?

Si tu empresa gestiona sistemas de autenticación interna o integra passkeys en tu producto, hay dos lecciones operativas inmediatas:

1. Valida el flag UV en todos tus endpoints. Si tu startup usa WebAuthn/FIDO2 para autenticar usuarios o empleados, asegúrate de que tu servidor valide explícitamente el bit UV en los datos del authenticator. No basta con configurar userVerification = required; debes verificar que ese flag esté efectivamente establecido en cada respuesta de autenticación. Sin esa validación, estás reduciendo tu MFA a un solo factor.

2. Trata la protección del endpoint como capa cero. Las passkeys no eliminan la necesidad de buena higiene de ciberseguridad en los dispositivos. Al contrario: si un atacante tiene malware en tu máquina, puede manipular señales de autenticación que antes eran imposibles de falsificar. Mantén actualizados los sistemas, usa protección antimalware activa y monitorea intentos de re-registro de dispositivos en tus gestores de credenciales.

Para startups que construyen productos B2B, considera también ofrecer soporte para gestores de contraseñas independientes como Bitwarden o 1Password, que ya soportan passkeys desde 2024. Esto mitiga el bloqueo de plataforma y da a tus clientes mayor portabilidad entre ecosistemas.

La pregunta abierta a 12 meses es si Apple, Google y Microsoft adoptarán el Credential Exchange Protocol de la FIDO Alliance para hacer las passkeys verdaderamente portables entre ecosistemas, resolviendo el problema del «jardín amurallado» que aún frena la adopción masiva.