Noticias
Pass-ta-key: el ataque a las passkeys de Google que no necesita tu huella (y la llave maestra que hoy no se puede rotar)
Investigadores de Unit 42, el equipo de research de Palo Alto Networks, publicaron el 3 de agosto de 2026 un informe que describe un ataque a las passkeys de Google sincronizadas en Chrome: malware que ya esté corriendo en una PC con Windows puede usar esas passkeys para entrar a las cuentas de la víctima sin pedir biometría ni PIN y sin ninguna interacción del usuario. Le pusieron Pass-ta-key.
Antes de que cierres el gestor de contraseñas y vuelvas a los papelitos: la criptografía de las passkeys no está rota, no hay ningún CVE asignado, y no se detectó ni un solo caso en el mundo real. Todo el ataque arranca desde un punto que conviene subrayar en amarillo: ya tenés malware adentro de la máquina. Ahora sí, la parte interesante.
Lo que vas a encontrar acá
- Qué encontró exactamente Unit 42
- Las tres variantes: Pass-ta-key, Silver y Golden
- La llave maestra que Google no puede cambiar
- Ojo: son DOS investigaciones distintas con casi el mismo nombre
- GitHub lo frenó, eBay no: todo dependía de un bit
- Qué queda fuera del alcance (y qué no se sabe)
- ¿Y esto qué significa para vos?
- Preguntas frecuentes
Qué encontró el ataque a las passkeys de Google
Cuando guardás una passkey en Google Password Manager, no se queda encerrada en tu PC: se sincroniza con tu Cuenta de Google para que puedas usarla en el celular y en la notebook. Para que eso sea seguro, Google monta lo que Unit 42 llama el cloud authenticator: un enclave aislado en la nube, más dos claves generadas en tu equipo y respaldadas por el TPM (ese chip que Windows 11 te pide sí o sí). Una es la identity key —el «algo que tenés»— y la otra la UV key, el «algo que sos o que sabés»: tu huella, tu cara, tu PIN.
El informe, firmado por el investigador Arie Olshtein, demuestra que un programa malicioso corriendo sin privilegios de administrador puede pedirle al TPM que firme por él. No rompe el chip ni descifra nada por fuerza bruta: usa las APIs criptográficas de Windows como las usaría Chrome, porque para el sistema operativo el pedido es legítimo. Lo dicen sin vueltas: los ataques «no rompen la criptografía subyacente», sino que aprovechan «las brechas entre los supuestos de diseño y las implementaciones del mundo real».
El alcance está declarado con una precisión que se agradece, y conviene leerlo textual antes de cualquier titular: la investigación «se enfoca en Google Password Manager en Chrome sobre Windows, específicamente en dispositivos equipados con un Trusted Platform Module (TPM). Todos los ataques presentados dependen de que ya exista malware en el dispositivo de la víctima en la etapa inicial».
Pass-ta-key, Silver y Golden: tres formas de la misma jugada
Los nombres evocan el bestiario clásico de la autenticación de Windows —Golden Ticket y Silver Ticket, de Kerberos; Pass-the-Hash, de NTLM—. Pero Unit 42 explica al menos el nombre base, y es bastante menos épico: «mezcla la palabra passkey y la frase ‘pass the key’, con un guiño al concepto de plato de pasta, ilustrando lo enredada que puede ponerse esta implementación de claves». Sí: el chiste es con los fideos.
| Variante | Qué se lleva el atacante | ¿Sirve fuera de tu PC? | El freno |
|---|---|---|---|
| Pass-ta-key | Una firma válida para entrar a un servicio como si fueras vos | No — necesita el malware activo y el TPM de tu equipo en cada login | La firma sale con el bit de verificación en 0: los sitios que lo controlan la rechazan |
| Silver Pass-ta-key | La capacidad de firmar con el bit de verificación en 1, registrando su propia clave | Sí — Unit 42 aclara que ya no hace falta acceso en vivo al equipo | Se corta desregistrando o volviendo a enrolar el dispositivo |
| Golden Pass-ta-key | El security domain secret: la clave maestra de 32 bytes que cifra todas tus passkeys sincronizadas | Sí, y del todo — descifra las claves privadas y firma sin pasar por Google | Prácticamente ninguno |
La escalera es clara: la primera variante es molesta, la segunda es grave y la tercera cambia la conversación. Para la Golden, el malware fuerza un nuevo registro del dispositivo y espía la memoria del proceso de Chrome justo en esa ventana, cuando la clave maestra pasa en texto plano. Google ya la sacó de los registros de diagnóstico de Chrome tras el reporte, pero —según el mismo informe— la clave sigue viajando al cliente y sigue quedando accesible en la memoria del navegador.
La llave maestra que Google, por ahora, no puede cambiar
Acá está el dato que casi ningún medio puso en el título. Cuando te roban una contraseña, la cambiás. Cuando te roban una cookie de sesión, cerrás sesión en todos lados. ¿Y cuando te roban el security domain secret?
«Incluso si se detecta el compromiso, la remediación es limitada. En la implementación actual de Google no hay forma de rotar ni revocar el SDS, lo que significa que todas las passkeys sincronizadas, actuales y futuras, siguen protegidas por la misma clave maestra.»
Unit 42 (Palo Alto Networks), informe Pass the Passkey — ver informe
Traducido: si esa clave se filtra una vez, limpiar la PC no alcanza. Las passkeys que crees después de desinfectar el equipo quedan protegidas por la misma llave que el atacante ya se llevó. No es una falla de criptografía: es una decisión de diseño sin plan de recuperación, y se arregla del lado de Google, no del tuyo.
Hay una tensión que vale la pena mirar de frente, sin exagerarla. En septiembre de 2024, presentando el PIN de Google Password Manager, Chirag Desai, product manager de Chrome, escribió en el blog oficial de Google que ese PIN «agrega una capa adicional de seguridad para asegurar que tus passkeys estén cifradas de extremo a extremo y no puedan ser accedidas por nadie, ni siquiera por Google». La promesa apunta a otro lado: a que las passkeys no queden legibles como datos sueltos en la nube. Unit 42 no verifica esa garantía ni la desmiente — de hecho, la única frase de Google que reproduce dice que el enclave existe para hacer que robar esas claves sea difícil, no imposible. Lo que muestra el informe está en el otro extremo del cable: la memoria de tu propia máquina.
«La función principal del autenticador de enclave (en la nube) es hacer que sea difícil robar los datos privados de las passkeys, que serían un objetivo obvio para el malware si estuvieran disponibles localmente.»
Respuesta de Google en el proceso privado de divulgación, citada por Unit 42 — no es una declaración pública sobre el informe. ver informe
Al cierre de esta nota, 4 de agosto de 2026, Google no publicó ninguna declaración sobre la investigación. Tanto BleepingComputer como The Hacker News dejaron constancia de que pidieron comentarios y de que, al momento de publicar, no había respuesta.
Ojo: son dos investigaciones distintas con casi el mismo nombre
Esta parte es el mayor riesgo de confusión de toda la historia. En la misma semana circularon dos investigaciones diferentes con nombres casi idénticos, y conviene tenerlas separadas antes de leer cualquier titular:
| Pass-ta-key (Unit 42) | Pass-the-Passkey (SpecterOps) | |
|---|---|---|
| Quién | Arie Olshtein, Unit 42 / Palo Alto Networks | Michael Grafnetter, SpecterOps |
| Cuándo | Informe del 3 de agosto de 2026 | Charla en Black Hat USA, 5 de agosto; anticipo en prensa el 22 de julio |
| A qué le pega | Google Password Manager + Chrome + Windows con TPM | Windows y Microsoft Entra ID |
| CVE | Ninguno («CVE» no aparece ni una vez en el informe) | CVE-2026-34348, severidad Importante, CVSS 6.5 |
| Parche | Google sacó la clave de los logs; sigue expuesta en memoria | Parcheado el 14 de julio de 2026 en el Patch Tuesday |
| La analogía de sus autores | Un plato de pasta | Pass-the-Hash y NTLM Relay, explícito en el abstract oficial |
Si leíste que «el ataque a las passkeys ya tiene parche», eso es el caso de Microsoft. Si leíste que «no hay CVE ni arreglo completo», eso es el de Google. Que Unit 42 haya titulado su informe Pass the Passkey —la misma frase que Grafnetter venía usando desde junio para su familia de ataques— no ayudó a nadie.
Grafnetter, cuyo trabajo es independiente y anterior al de Unit 42 y no se refiere a él, resumió a Dark Reading una postura que le viene bien a esta nota entera:
«Las passkeys siguen siendo una mejora importante sobre las contraseñas, pero no son magia. Nuestra investigación muestra que si la implementación que las rodea está mal hecha, los atacantes pueden reintroducir caminos de replay, relay y tipo phishing incluso cuando la criptografía de WebAuthn es sólida.»
Michael Grafnetter, principal security researcher en SpecterOps — vía Dark Reading
En esa misma entrevista aclara que los caminos de ataque siguen siendo mucho más complejos que los de las contraseñas tradicionales y que por eso sigue recomendando adoptar passkeys. No es una voz apocalíptica: es una voz que pide leer la letra chica.
GitHub lo frenó, eBay no: todo dependía de un bit
El detalle más didáctico del informe: la misma passkey, con el mismo ataque, dio resultados opuestos según el sitio. Cuando el malware pide una firma, esa firma viaja con un indicador que dice si hubo verificación del usuario —huella, cara o PIN—. En el ataque base ese indicador queda en cero.
GitHub lo controla y devolvió un error seco: pedile la contraseña. eBay pedía verificación pero no controlaba el indicador, así que el ataque entró; Unit 42 aclara que lo corrigió tras el reporte. Un bit de diferencia entre «cuenta segura» y «cuenta tomada», y la decisión no estaba ni en Google ni en vos: estaba en cada sitio donde usás la passkey. Con el matiz honesto de que esa validación frena la variante básica, pero no la Silver ni la Golden, que aprenden a poner ese bit en 1 o a saltearse el circuito entero.
Qué queda fuera del alcance (y qué no se sabe)
| Situación | Estado real |
|---|---|
| Tu Windows sin malware | No hay ataque posible: es la precondición de las tres variantes |
| Passkeys en iOS y Android | ⚠️ Fuera del alcance del estudio. El informe sí aclara que ahí Google Password Manager no usa el autenticador en la nube y tiene que obtener la clave maestra para descifrar las passkeys. Nadie testeó ataques contra esa arquitectura: no está analizada, que no es lo mismo que «está a salvo» |
| Otros navegadores que no sean Chrome | No evaluados |
| Passkeys ligadas al dispositivo y llaves físicas | Fuera de este vector: los tres ataques dependen de la sincronización en la nube (inferencia nuestra; el informe no las menciona). Sin generalizar: SpecterOps sí encontró firmas de YubiKey expuestas en Windows, ya parcheado el 14-jul-2026 |
| 1Password, Bitwarden, iCloud Keychain | No evaluados. Unit 42 advierte que el modelo de autenticador en la nube lo usan varios proveedores |
| Casos reales de explotación | Cero. Los únicos cambios concretos hasta hoy son la corrección de eBay y la limpieza de los logs de Chrome |
Para dimensionar: según la FIDO Alliance, en mayo de 2026 ya había 5.000 millones de passkeys en uso. La tecnología no está en discusión: sigue siendo mejor que la contraseña reciclada de siempre. Lo que está en discusión es qué pasa cuando el equipo donde vive esa passkey ya está tomado.
Si querés repasar cómo funcionan, este es el explicativo oficial del canal de Google Chrome. Aclaración necesaria: es material general de 2024, no una respuesta de Google a esta investigación.
¿Y esto qué significa para vos?
Si tenés una PC con Windows, Chrome y las passkeys de Google activadas —o una PyME donde los equipos son de todos y de nadie—, la lectura práctica es corta y bastante liberadora: no tenés que dejar de usar passkeys. Seguís mucho mejor que con una contraseña repetida en catorce sitios. Lo que cambia es dónde ponés el foco.
La cadena entera arranca en un solo eslabón: malware ejecutándose en tu Windows. Ese es el punto donde se corta, y es el mismo eslabón del que veníamos hablando en el falso instalador de Windows que circula por el wifi de los hoteles. Cambia el disfraz, no la puerta de entrada. Así que el trabajo es el aburrido de siempre: no ejecutar instaladores de dudosa procedencia, mantener Windows y Chrome al día, y tener protección en tiempo real corriendo — si tu equipo no tiene, un antivirus con licencia original es el piso razonable.
Tres cosas concretas que sí podés hacer hoy, sin drama:
- Revisá qué passkeys tenés y en qué dispositivos, en
myaccount.google.com/signinoptions/passkeys. Si aparece un equipo que ya no usás, sacalo. - Para las cuentas que más te importan —banco, correo principal, la cuenta desde la que se recupera todo lo demás— evaluá una llave física o una passkey ligada al dispositivo, que no se sincroniza y queda fuera de este vector (y parcheá Windows: la otra investigación de esta nota tocó justamente ese flanco).
- Si sospechás que la PC estuvo comprometida, limpiar el equipo no es el final. Revisá los dispositivos vinculados a tu Cuenta de Google, cerrá las sesiones que no reconozcas y tratá las cuentas críticas como si hubieran estado expuestas.
Y una advertencia de expectativas, porque acá TCD vende antivirus y sería muy fácil hacer trampa: ningún antivirus del mercado promete detener específicamente esta técnica, y las fichas de estos productos no hablan de proteger passkeys. Lo que sí hacen es protección en tiempo real contra malware, que es precisamente la precondición sin la cual nada de esto ocurre. Esa es la relación honesta: no es un escudo contra Pass-ta-key, es la capa que evita el paso cero.
Preguntas frecuentes sobre Pass-ta-key y las passkeys sincronizadas
¿Tengo que dejar de usar passkeys?
No. La criptografía de las passkeys no fue vulnerada y los propios investigadores las describen como un avance real frente a las contraseñas. El ataque exige que ya haya malware ejecutándose en tu PC con Windows. Si tu equipo está limpio, ninguna de las tres variantes te alcanza.
¿Google ya arregló la falla de las passkeys?
Parcialmente. Tras el reporte, Google quitó la clave maestra de los registros de diagnóstico de Chrome. Pero según Unit 42 esa clave sigue llegando al equipo y queda accesible en la memoria del navegador, y todavía no existe forma de rotarla ni revocarla. Al 4 de agosto de 2026 Google no hizo declaraciones públicas.
¿Las passkeys de mi celular Android o iPhone están afectadas?
La investigación no las cubre: se limitó a Chrome sobre Windows con chip TPM. El informe sí menciona que en móvil la clave maestra llega al dispositivo por diseño, porque esas versiones no usan el autenticador en la nube, pero nadie publicó ataques prácticos contra esa arquitectura.
¿Se robaron cuentas reales con el ataque Pass-ta-key?
No hay ningún caso reportado. Ninguna de las fuentes que cubrió el informe describe explotación en el mundo real, y tampoco se asignó un CVE. Es investigación divulgada de forma responsable: el único efecto sobre un servicio concreto fue que eBay corrigió una validación tras el aviso.
🛒 Te puede servir — para el paso cero, no para la passkey
¿Y vos qué opinás? Dejalo en los comentarios ⬇️
Blindá el paso cero: mirá los antivirus originales →
