Un investigador de la Unidad 42 de Palo Alto Networks ha publicado un informe detallado de tres ataques que permiten que un malware se haga con cuentas protegidas por passkeys almacenadas en Google Password Manager. El trabajo se conoce como Pass-ta-key, un nombre que funde passkey con la expresión pass the key y añade, de propina, un plato de pasta. Arie Olshtein, el investigador que publicó el informe, presentó los hallazgos como una superficie de ataque novedosa para la autenticación sin contraseña. Las reacciones del resto de profesionales de la seguridad han sido más mesuradas: la técnica exige que el malware ya se esté ejecutando en la máquina de la víctima, lo que significa que el modelo de seguridad de las passkeys nunca fue diseñado para sobrevivir a eso.
Los ataques tienen como objetivo las passkeys sincronizadas de Google Password Manager dentro de Chrome en Windows, donde el sistema operativo funciona con un módulo de plataforma segura (TPM). En la variante más sencilla, el malware extrae una clave de identidad respaldada por hardware de un archivo que Chrome conserva en el disco y la usa para firmar solicitudes de autenticación en silencio. No interviene ninguna huella dactilar, PIN ni aviso en pantalla. La variante más potente, Golden Pass-ta-key, recupera el secreto del dominio de seguridad de Google, la clave maestra que protege todas las passkeys sincronizadas, y descifra el conjunto completo hasta convertirlo en una forma compartible que funciona en cualquier dispositivo.
El motivo de que estos ataques sean posibles es específico de Windows. Según las especificaciones FIDO 2 y WebAuthn, las passkeys no tienen por qué residir en hardware de seguridad dedicado, como un TPM o un enclave seguro. En macOS, iOS y Android, las passkeys se almacenan localmente en el dispositivo, donde el aislamiento de las aplicaciones mantiene el malware alejado de las claves privadas. Windows es la excepción: las aplicaciones suelen ejecutarse con los privilegios del usuario conectado, y su aislamiento protege a las aplicaciones en una sola dirección. Por eso Google Password Manager y aplicaciones de terceros, como 1Password y Dashlane, guardan las passkeys de Windows en bóvedas alojadas en la nube y protegidas con cifrado de extremo a extremo, en lugar de hacerlo en la propia máquina; un diseño que mantiene las claves fuera del alcance del malware local, pero que crea una nueva relación de confianza del lado del servidor que atacar. Microsoft sigue siendo casi el único que ofrece almacenamiento de passkeys basado en TPM, principalmente para clientes empresariales.
El informe de Olshtein documenta la mecánica con detalle. Chrome guarda un índice de las credenciales de passkey sincronizadas del usuario en un archivo de base de datos local cuya lectura no requiere privilegios elevados, y que revela en qué sitios registró el usuario passkeys y dónde se almacenan las claves privadas cifradas. Para el ataque Pass-ta-key básico, el malware copia una clave de identidad envuelta del archivo de estado de passkeys de Chrome y luego usa las API criptográficas estándar de Windows para firmar solicitudes del mismo modo en que lo haría el propio Chrome. La solicitud firmada se envía al autenticador en la nube de Google, que la trata como procedente de un dispositivo de confianza y devuelve una aserción de inicio de sesión válida.
Que esa aserción sea aceptada por el sitio en el que se inicia sesión depende de un único bit en los datos de autenticación: el indicador de usuario verificado. Cuando una solicitud se firma con la clave de verificación, el indicador se activa; cuando se firma solo con la clave de identidad, no. Los servicios que exigen la verificación del usuario y de hecho validan el indicador, como hace GitHub, rechazaron el ataque en las pruebas de la Unidad 42. eBay lo aceptó pese a exigir ese requisito, porque en ese momento no validaba el indicador; la empresa corrigió la laguna tras la divulgación. Un segundo ataque, Silver Pass-ta-key, abusa del flujo de reinscripción de dispositivos para registrar una clave de verificación controlada por el atacante, lo que permite iniciar sesión desde una máquina que la víctima nunca tocó.
El argumento más amplio de los críticos con el marco de la superficie de ataque novedosa es que lo que está en juego es lo mismo que con cualquier otra credencial en una máquina comprometida. Una vez que un dispositivo está infectado y se ha iniciado sesión en cuentas sensibles, un atacante normalmente puede acceder a contraseñas, cookies de sesión y a todo lo demás a lo que la cuenta pueda llegar. Las passkeys están diseñadas para frenar el phishing y el robo de credenciales desde los servidores, no para resistir un dispositivo completamente comprometido. Aun así, la investigación tiene valor práctico: muestra que algunos servicios tratan el indicador de usuario verificado como prueba de un evento biométrico o de PIN real, y proporciona a Google y a otros proveedores una lista de comprobación concreta para reforzar el registro de dispositivos, la recuperación y la verificación del lado del servidor.
Para los usuarios, la conclusión no cambia. Las passkeys siguen neutralizando los ataques más comunes contra las contraseñas, como los sitios de phishing y el relleno de credenciales con contraseñas reutilizadas. Mantener Windows parcheado y con protección antimalware actualizada sigue siendo la defensa eficaz, porque todos los ataques comienzan con un malware que ya se ejecuta en la máquina.
Traducido por Alessandra
Sources: Pass the Passkey: A Novel Attack Surface in Passwordless Authentication (Unit 42, Aug 2026); New Pass-ta-key attack reveals all the things we didn’t know about passkeys (Ars Technica, Aug 2026); Google’s synchronized passkeys can be stolen in ‘Pass-ta-key’ attacks (Malwarebytes, Aug 2026); Pass-ta-key Research Exposes Gaps in Google’s Passkey Security on Windows (BetaNews, Aug 2026)