Tu passkey no se rompe: se copia la llave maestra

El 3 de agosto, Unit 42 publicó tres maneras de entrar en cuentas protegidas con passkey sin romper una sola línea de criptografía. Ninguna necesita permisos de administrador. La primera no pide huella, ni PIN, ni hace aparecer nada en la pantalla; las otras dos entran por el reenrolamiento del dispositivo, así que el usuario ve la pantalla de siempre pidiéndole el PIN de recuperación de Google, lo teclea sin sospechar nada y el trabajo sucio ocurre detrás. Y todas empiezan en el mismo sitio: un Windows en el que ya está corriendo un programa malicioso. Lo importante, en la primera frase, para que nadie se lleve la idea equivocada: seguimos recomendando passkeys. Lo que se ha caído no es la tecnología, es una frase de marketing.

Las tres puertas, en orden

El trabajo se llama Pass the Passkey y apunta a un sitio muy concreto: el autenticador en la nube del gestor de contraseñas de Google dentro de Chrome, en Windows con TPM. No hay CVE asignado. Hay tres técnicas, y conviene entenderlas por separado porque no dan lo mismo.

• Pass-ta-key. El malware se hace pasar por el dispositivo de confianza usando la clave de identidad que Chrome tiene respaldada por el TPM, y pide una respuesta de autenticación. El detalle que decide si funciona o no es un solo bit: la aserción va con la marca de «usuario verificado» sin activar. Contra un servicio que comprueba ese bit, no vale. Contra uno que no lo comprueba, sí — y el ejemplo publicado es eBay, que las aceptaba hasta que se lo comunicaron, mientras que GitHub ya lo validaba.
• Silver Pass-ta-key. Sube un escalón: fuerza un reenrolamiento del dispositivo y, durante esa ventana de recuperación, registra una clave de verificación de usuario del atacante. La palanca es de una sencillez incómoda: basta con borrar el fichero de estado local del enclave, y los investigadores anotan que «no hay ninguna protección incorporada que impida su eliminación». A partir de ahí el bit de «usuario verificado» viene activado de verdad, así que comprobarlo ya no salva: la aserción es legítima, solo que quien la firma no eres tú.
• Golden Pass-ta-key. La grave. Durante ese mismo reenrolamiento, el secreto del dominio de seguridad —32 bytes, la clave que cifra todas las passkeys sincronizadas de la cuenta— pasa brevemente en claro por la memoria del proceso de Chrome, y de ahí se saca. Con esos 32 bytes se descifran las claves privadas de todas las passkeys sincronizadas, no la de un sitio. Y una frase de los investigadores que conviene no leer por encima: «en la implementación actual de Google no hay forma de rotar ni revocar el secreto, lo que significa que todas las passkeys sincronizadas, actuales y futuras, siguen protegidas por la misma clave maestra».

Google retiró ese secreto de la salida de registro de FIDO después del aviso de los investigadores. La frase que cierra ese punto en la investigación es la que hay que leer despacio: «el secreto se sigue enviando al cliente y sigue siendo accesible en la memoria del proceso de Chrome». Es decir: se arregló que quedara escrito en un log; no se arregló que esté ahí.

Una llave maestra de 32 bytes

Piensa en una sala de cajas de seguridad. Cada caja tiene su cerradura, distinta de todas las demás e imposible de forzar con la llave de la caja vecina: eso es exactamente una passkey, un par de claves único por sitio que no vale en ningún otro. Pero como el cliente quiere poder abrir su caja desde cualquier oficina de la entidad, alguien decidió que existiera una llave que las abre todas y que viaja con él. Esa llave es la comodidad. Y esa llave son los 32 bytes.

Esto no es un descuido de nadie: es el precio de la sincronización, y estaba puesto encima de la mesa desde el principio. Querer las passkeys en el móvil, en el portátil y en el ordenador de casa obliga a que exista un secreto recuperable en algún sitio; si no existiera, cambiar de teléfono significaría perder todas las cuentas. Lo que ha hecho esta investigación no es descubrir la llave maestra, es enseñar lo cerca que está del suelo: al alcance de un proceso que se ejecuta con el usuario normal de Windows, sin más privilegios que los suyos.

Lo que esto NO es

Toca la parte aburrida, que es la que evita decisiones malas. Esto no rompe WebAuthn ni FIDO2. No hay ningún fallo matemático, ninguna clave privada adivinada, ningún algoritmo caído. No basta con visitar una web. No hay descrita ninguna campaña criminal usándolo. Y todo parte de una máquina que ya está perdida: los propios investigadores lo resumen diciendo que «todos los ataques presentados dependen de que ya exista malware en el dispositivo de la víctima».

El matiz que juega en contra del titular fácil también es verdad: si tienes un programa malicioso leyendo la memoria del navegador, tenías un problema grave antes del 3 de agosto. Las cookies de sesión ya se robaban así, y con una cookie de sesión válida tampoco hace falta autenticarse. Esto no abre la brecha. Lo que hace es ampliar el botín: donde antes se llevaban las sesiones abiertas de ese equipo, ahora se pueden llevar las llaves de todas las cuentas sincronizadas, también las que no habías abierto en ese portátil.

Por qué importa igual

Importa porque la posición de partida que estas tres técnicas dan por supuesta —un Windows con malware corriendo como usuario normal— no es una hipótesis de laboratorio: es un producto. Los números que publica SpyCloud sobre 2025 describen esa industria: 13,2 millones de infecciones de programas ladrones de credenciales, 642,4 millones de credenciales recuperadas de esas infecciones y 8.600 millones de cookies y artefactos de sesión recuperados de fuentes criminales. Ese último número es el que importa aquí, porque son exactamente el mismo tipo de secreto: material que se roba de la máquina, no de la persona.

Hace dos días escribíamos sobre el token que no vuelve a pedir MFA. Allí el problema era a quién le habías dado permiso; aquí es dónde vive la prueba de que eres tú. La pregunta es distinta y el punto ciego es el mismo, pero la escala no: una cookie robada te da una sesión de un servicio, y estos 32 bytes te dan la caja entera.

Y aun así: passkeys sí

Nos mojamos, porque un post que solo asusta no sirve de nada. Una passkey sigue siendo mejor que cualquier cosa que hubiera antes, y por un motivo que esta investigación no toca: está atada al dominio. No se puede escribir en una web falsa, no se puede dictar por teléfono, no se puede reenviar a nadie por WhatsApp. El phishing y la ingeniería social se quedan sin objeto. Por eso Microsoft está retirando el SMS como segundo factor y empujando exactamente hacia aquí, y por eso nosotros las seguimos recomendando.

Lo que se cae no es la decisión: es la coletilla que la acompañaba. «Con passkeys ya no hay que preocuparse del puesto de trabajo» nunca estuvo en el trato, aunque se haya repetido en muchas presentaciones —incluidas algunas en las que estábamos sentados nosotros. Sustituir la contraseña resuelve el robo de la contraseña. No resuelve el robo del sitio donde guardas lo que la sustituye.

Cinco cosas que sí se pueden hacer esta semana

• Si publicas un servicio con WebAuthn, comprueba el bit que vuelve. La recomendación de los investigadores es literal: poner userVerification en required y verificar la marca de usuario verificado que devuelve la aserción, en vez de fiarse de lo que pediste al hacer la petición. Es un par de líneas en el servidor y es lo que separa a eBay de GitHub en esta historia.
• Decide dónde viven las passkeys de la empresa. Una passkey de una cuenta corporativa sincronizada en el perfil personal de Chrome de un empleado no está bajo control de la empresa: no se audita, no se revoca desde ningún panel y no se queda en el portátil el día que la persona se va. Esto no es un problema técnico nuevo, es de gobierno, y es el mismo que ya tenías con las contraseñas guardadas en el navegador.
• Alerta sobre las altas, no solo sobre los inicios de sesión. Dos de las tres técnicas pasan por un reenrolamiento del dispositivo. Un dispositivo nuevo dado de alta en una cuenta debería generar un aviso al menos tan visible como un inicio de sesión desde otro país. En la mayoría de sitios, hoy, no lo genera — y no es una idea nuestra: la sexta recomendación de la investigación es exactamente esa, mejorar la detección de uso anómalo de passkeys.
• Asume que limpiar el equipo no cierra el caso. Este es el punto que más cuesta digerir: en la implementación actual de Google no hay forma de rotar ni revocar ese secreto —lo dicen los investigadores con esas palabras—, así que crear una passkey nueva no cierra el agujero, porque nace protegida por la misma llave maestra. Un equipo que ha tenido un ladrón de credenciales obliga a tratar las passkeys sincronizadas de esa cuenta como comprometidas y a resolverlo en la cuenta, no en el portátil. Formatear el portátil es la parte fácil.
• Pon la detección donde ocurre el ataque. Ninguna de estas tres técnicas se ve desde el portal de identidad: no hay inicio de sesión raro, no hay país imposible, no hay reto de MFA fallido. La única capa que está mirando en el sitio correcto es la que corre dentro del equipo. Es la misma conclusión a la que llegamos con el agente de gestión de un proveedor: cuando el ataque usa mecanismos legítimos, la señal no está en el registro central, está en la máquina. Lo que no vale como respuesta es volver a la contraseña con SMS: sería cambiar un riesgo que necesita malware en tu equipo por otro que solo necesita una llamada de teléfono bien hecha.

El eslabón se ha movido, no ha desaparecido

Durante veinte años el eslabón débil de la identidad fue la contraseña, y toda la industria —nosotros incluidos— construyó alrededor de esa idea: políticas de complejidad, gestores, caducidades, segundos factores. Las passkeys se llevan ese problema por delante, y está muy bien. Lo que no se llevan es la necesidad de que alguien mire el equipo desde el que trabaja la persona, con su navegador, sus extensiones, sus descargas y su usuario con prisa.

Por eso la pregunta que separa una política de identidad seria de una diapositiva no es «¿ya tenemos passkeys?». Es «si mañana un portátil nuestro se lleva un ladrón de credenciales, ¿cuántas cuentas damos por comprometidas y en cuánto tiempo las resolvemos?». Si la respuesta es «ninguna, tenemos passkeys», ya sabes qué hay que revisar.

Fuentes (verificadas): investigación Pass the Passkey: A Novel Attack Surface in Passwordless Authentication, de Unit 42 (Palo Alto Networks), 03-08-2026 — nombres de las tres técnicas; alcance («Google Password Manager en Chrome sobre Windows, en dispositivos equipados con TPM»); requisitos (sin escalada de privilegios, sin desbloqueo del dispositivo y sin interacción del usuario en la primera técnica; las otras dos pasan por el reenrolamiento, durante el cual Chrome pide al usuario el PIN de recuperación del gestor); la marca de usuario verificado sin activar y el caso de eBay —«tras nuestro informe, eBay corrigió esa brecha de verificación y ahora valida correctamente la marca de UV»— frente a GitHub; el borrado del fichero de estado del enclave, «sin protecciones incorporadas que impidan su eliminación»; el secreto del dominio de seguridad de 32 bytes extraído de la memoria del proceso de Chrome; «en la implementación actual de Google no hay forma de rotar ni revocar el secreto…»; «todos los ataques presentados dependen de que ya exista malware en el dispositivo de la víctima»; la retirada del secreto de la salida de registro de FIDO por parte de Google con la precisión de que «el secreto se sigue enviando al cliente y sigue siendo accesible en la memoria del proceso de Chrome»; y las seis recomendaciones, incluida la de mejorar la detección de uso anómalo de passkeys (citas traducidas por nosotros del original en inglés). La ausencia de CVE asignado y el encuadre como técnicas de post-compromiso, en la cobertura de The Hacker News, 03-08-2026 y BleepingComputer, 03-08-2026. Cifras de 2025 (13,2 millones de infecciones de programas ladrones de credenciales, 642,4 millones de credenciales recuperadas de esas infecciones y 8.600 millones de cookies y artefactos de sesión recuperados de fuentes criminales): SpyCloud, 2026 Identity Exposure Report. El criterio, la lectura del caso y las opiniones son nuestros.