¿Son seguras las passkeys? Qué rompieron realmente los ataques Pass-ta-key (agosto de 2026)

Divulgación de afiliación - este artículo contiene un enlace de afiliado a un gestor de contraseñas. Si te suscribes a través de él ganamos una comisión sin coste adicional para ti. No cambia nada de lo que sigue: los hallazgos de abajo proceden de Palo Alto Networks Unit 42 y de la prensa técnica, y están atribuidos fuente por fuente.

Respuesta corta: sí, las passkeys siguen siendo seguras de usar, y los investigadores que publicaron el ataque lo dicen con todas las letras. El 3 de agosto de 2026, Unit 42 de Palo Alto Networks demostró que un malware ya en ejecución en un PC con Windows puede secuestrar passkeys sincronizadas mediante Google Password Manager. Su propia frase es la que hay que recordar: «These attacks do not break the underlying cryptography.» («estos ataques no rompen la criptografía subyacente»). Lo que rompieron es la fontanería que rodea a la passkey, no la passkey.

Esa distinción es toda la historia, y la mayoría de los titulares la dejaron caer.

Qué se publicó realmente

Arie Olshtein, investigador de Unit 42, publicó «Pass the Passkey: A Novel Attack Surface in Passwordless Authentication» el 3 de agosto de 2026. Es una entrada de blog de investigación técnica, no un artículo revisado por pares, y procede de un proveedor comercial de seguridad, conviene decirlo con franqueza, porque es detallada y creíble pero no es un tercero neutral.

Describe tres técnicas, llamadas en conjunto los ataques Pass-ta-key.

Pass-ta-key, el malware extrae del disco o de la memoria la clave privada de identidad del dispositivo envuelta, y luego llama a las API CNG de Windows (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) para que el TPM firme en su nombre. Firma el hash del handshake WebSocket y se hace pasar por una instalación legítima de Chrome ante el autenticador en la nube de Google. Sin desbloqueo del dispositivo, sin interacción del usuario, sin escalada de privilegios. Fíjate en la sutileza: la clave nunca sale del TPM, simplemente se hace que el TPM trabaje para el atacante.

Silver Pass-ta-key, el malware borra passkey_enclave_state para forzar un nuevo registro del dispositivo, explota el estado transitorio uv_key_pending e inscribe su propia clave de verificación de usuario. El fallo es preciso: el autenticador en la nube no valida la atestación de las claves UV recién registradas, por lo que no puede saber si provienen de hardware seguro. Resultado: acceso reutilizable desde otra máquina, sin el dispositivo de la víctima.

Golden Pass-ta-key, el peor de los tres. El Security Domain Secret, una clave maestra de 32 bytes que protege cada passkey sincronizada, se extrae de la memoria del proceso de Chrome durante el nuevo registro. Con ella, un atacante descifra los registros de credenciales almacenados y se lleva todas las passkeys sincronizadas de la cuenta.

Los dos hechos que hacen esto serio

Google eliminó el Security Domain Secret de los registros de diagnóstico de Chrome tras la divulgación. Pero Unit 42 afirma que el secreto se sigue enviando al cliente y permanece accesible en la memoria del proceso de Chrome, reconocido, no corregido.

Y no hay forma de rotar ni revocar esa clave maestra en la implementación actual. Las passkeys presentes y futuras quedan protegidas por el mismo secreto. Esa es la parte más dura de este asunto, y la que no tiene ninguna solución del lado del usuario.

La única condición que lo cambia todo

Todas estas técnicas dan por supuesto que hay malware ya en ejecución en la máquina. Los investigadores lo dicen: «malware already existing on the victim's device during the initial stage.» («malware ya presente en el dispositivo de la víctima durante la fase inicial»).

Frank Dickson, de IDC, dio la formulación más clara, en Computerworld: «This isn't passkeys getting hacked from across the internet. It's what [an attacker] does once they're already inside the house.» («esto no son passkeys hackeadas desde el otro lado de internet; es lo que hace [un atacante] cuando ya está dentro de casa»).

Así que el perímetro es estrecho y concreto:

No hace falta phishing, ni una extensión maliciosa, ni una sesión robada, ni una degradación a otro factor. Y no hay explotación remota: si tu máquina está limpia, nada de esto te alcanza.

iCloud Keychain de Apple, Windows Hello, 1Password y Bitwarden no fueron probados. Unit 42 observa que otros proveedores usan un diseño de autenticador en la nube similar, lo cual es una advertencia sobre la arquitectura: no un hallazgo de que sean vulnerables. Quien te diga que «todas las passkeys están afectadas» va más allá de la investigación.

Qué merece la pena cambiar

Si eres un particular. El único cerrojo real aquí es el requisito previo: mantener el malware fuera de la máquina. La recomendación de la propia Unit 42 es invertir en protección del endpoint y tratar las passkeys como una capa dentro de una estrategia más amplia, y no como una meta final. Para tus cuentas de mayor valor, correo, banca, registrador de dominios, una llave de seguridad física es la opción ligada al dispositivo que esta investigación no toca, ya que nada se sincroniza con un enclave en la nube. Eso es un compromiso, no un veredicto: ganas resistencia a esta clase de ataque y pierdes la comodidad de sincronizar entre dispositivos.

Si gestionas un servicio. La corrección concreta es del lado del servidor y está nombrada: exigir userVerification y validar realmente el indicador UV en la respuesta de autenticación. Esto no es hipotético, eBay estaba aceptando autenticaciones sin verificación de usuario mientras userVerification estaba fijado en required, y lo corrigió tras el informe de Unit 42. GitHub rechazó correctamente el mismo ataque. Una implementación sólida aguanta; una desigual no. Como resumió el analista Justin Greis en Computerworld: «The specification is sound, but the ecosystem implementing it is uneven.» («la especificación es sólida, pero el ecosistema que la implementa es desigual»).

Más allá de eso, las medidas documentadas por los investigadores y por los analistas citados en Computerworld: validar la atestación de la clave del dispositivo en el registro, vigilar el uso anómalo de passkeys, desplegar EDR y detección de amenazas de identidad (ITDR), fijar una política explícita sobre credenciales sincronizadas frente a ligadas al dispositivo, y ensayar los flujos de recuperación, porque la recuperación y el nuevo registro son precisamente de lo que abusan estos ataques.

Qué no hay que concluir

Varias afirmaciones que circulan esta semana no están respaldadas por la investigación, y repetirlas sería un error:

• «Las passkeys están muertas / rotas.» Contradicho por escrito por Unit 42 y SecurityWeek.
• «Se ha descifrado la criptografía.» No fue así, explícitamente.
• «Vuelve a las contraseñas.» Ninguna fuente lo recomienda, y reintroduciría el phishing y la reutilización de credenciales, justo los ataques que las passkeys eliminan.
• «Es un CVE explotado activamente.» No se había asignado ningún CVE a fecha de 3 de agosto, y no se ha informado de ninguna explotación real.
• «Apple y Microsoft también están afectados.» No probado. No es lo mismo.

El resumen honesto pertenece a la propia Unit 42: las passkeys son «a meaningful step forward in authentication security» («un avance significativo en la seguridad de la autenticación») porque eliminan los secretos compartidos y, con ellos, clases enteras de ataques. Esta investigación no invierte eso. Muestra que el ecosistema construido alrededor de las passkeys, registro, recuperación, sincronización en la nube, merece el mismo escrutinio que ya recibió la criptografía.

La lección de fondo, planteada por J. Wolfgang Goerlich en Computerworld, es la que conviene retener: las passkeys sincronizadas reintrodujeron un riesgo de portabilidad de credenciales que los autenticadores ligados al dispositivo nunca tuvieron. La comodidad entre dispositivos tiene un precio, y esta es la primera vez que podemos verlo con claridad.

Fuentes

• Arie Olshtein, «Pass the Passkey: A Novel Attack Surface in Passwordless Authentication», Palo Alto Networks Unit 42, 3 de agosto de 2026, fuente primaria, proveedor comercial de seguridad.
• BleepingComputer, 3 de agosto de 2026, primera cobertura, señala que no se asignó ningún CVE.
• The Hacker News, 3 de agosto de 2026, «the attacks go after the code around the passkey» («los ataques van a por el código que rodea a la passkey»).
• SecurityWeek, 5 de agosto de 2026, «That does not mean passkeys are broken» («eso no significa que las passkeys estén rotas»).
• Computerworld, Evan Schuman, 5 de agosto de 2026, comentarios de analistas (Dickson, Greis, Goerlich, Levine, Finkelstein).
• Biometric Update, 7 de agosto de 2026, la posición vigente de la FIDO Alliance, sin explotación real.

Cifras y declaraciones verificadas el 9 de agosto de 2026. Google no había hecho ninguna declaración pública sobre el fondo del asunto en esa fecha; es el punto que con más probabilidad ha cambiado desde entonces.