Pass-ta-key: qué significa realmente el ataque a las passkeys de Google

¿Son inseguras las passkeys después de todo? Esa es precisamente la pregunta que plantea Pass-ta-key.

Palo Alto Networks Unit 42 describe tres cadenas de ataque con las que un malware puede abusar de passkeys sincronizadas por Google, eludir la verificación del usuario y, en el escenario más grave, extraer todas las claves privadas de passkeys de una cuenta.

Ninguna de las tres técnicas rompe WebAuthn, FIDO2 ni la criptografía de clave pública utilizada. Todas presuponen que ya se ejecuta malware en el PC Windows de la víctima. Es una limitación importante.

Sin embargo, afirmar que «en un endpoint comprometido todo está perdido de todos modos» es un análisis demasiado cómodo. La variante Golden Pass-ta-key pretende convertir una intrusión local en un paquete exportable y reutilizable de todas las passkeys sincronizadas. Su impacto va más allá del robo de una única sesión del navegador.

La valoración breve

Sí, es un tema de seguridad nuevo y con entidad propia. Pero no es motivo para abandonar las passkeys ni para volver a depender exclusivamente de contraseñas.

La clasificación correcta es esta:

• El protocolo resiste: no se rompen el Origin Binding, el modelo challenge-response ni la criptografía asimétrica.
• Se ataca una implementación concreta: la combinación estudiada por Unit 42 de Google Password Manager, Chrome, Windows y un TPM.
• El endpoint ya debe estar comprometido: no es un ataque que cualquier sitio web pueda lanzar desde Internet contra un equipo limpio.
• El daño potencial sigue siendo considerable: las variantes van desde generar silenciosamente una assertion de inicio de sesión hasta extraer las claves privadas de todas las passkeys sincronizadas.
• Las passkeys sincronizadas y las vinculadas a un dispositivo tienen perfiles de riesgo diferentes: ambas son passkeys, pero no ofrecen el mismo nivel de seguridad.
• Las contraseñas siguen siendo la alternativa peor: además pueden sufrir phishing, reutilización, ataques de adivinación y robo desde bases de datos de servidores.

Por eso mi valoración de riesgo no es «no pasa nada», sino: alcance técnico limitado y requisitos exigentes, pero un impacto potencialmente muy alto si el ataque tiene éxito.

Alcance técnico y evidencias

El estado demostrado a 31 de agosto de 2026 incluye los flujos de ataque documentados por Unit 42, la especificación WebAuthn, la documentación de passkeys de Google, el issue público de Chromium y las directrices actuales de NIST para autenticadores sincronizables. A ello se suman Pass-the-Passkey de SpecterOps, CVE-2026-34348, el downgrade FIDO de Proofpoint y los hallazgos técnicos de Expel y SquareX.

La investigación se publicó el 3 de agosto y Unit 42 la actualizó el 14 de agosto. Se refiere expresamente a Google Password Manager en Chrome sobre Windows y en dispositivos con Trusted Platform Module. Otros navegadores, sistemas operativos y proveedores de passkeys pueden plantear cuestiones arquitectónicas parecidas, pero estos tres ataques no se han demostrado contra ellos.

No existe una campaña activa documentada que utilice estas técnicas concretas en entornos reales. Las evidencias actuales proceden de investigación, pruebas de concepto y Responsible Disclosure. Esta distinción importa: una técnica demostrada no equivale automáticamente a una explotación masiva.

Qué protege realmente una passkey

Una passkey no es una contraseña especialmente larga. Es una credencial WebAuthn basada en criptografía asimétrica.

Durante el registro, el autenticador genera un par de claves:

private key -> remains with the authenticator
public key  -> is registered with the online service

El servicio online, denominado Relying Party en WebAuthn, almacena la clave pública junto con una Credential ID y la cuenta del usuario. En un inicio de sesión posterior, el servicio envía un challenge nuevo y aleatorio. El autenticador firma datos que vinculan, entre otros elementos, ese challenge y el contexto del sitio web que realizó la llamada. El servidor verifica la firma con la clave pública registrada.

La clave privada no se transmite al servidor como una contraseña. En condiciones ideales, una filtración en el servicio solo proporciona claves públicas al atacante, con las que no puede generar firmas válidas.

También es esencial la vinculación con la Relying Party ID y el origen web. Una passkey de example.com no genera en un dominio de phishing parecido una assertion válida para example.com. El usuario no dispone de un secreto que pueda introducir en el sitio equivocado o revelar por teléfono.

Eso es exactamente lo que significa resistente al phishing. NIST define el concepto de forma estricta: un verificador fraudulento no debe obtener ni el secreto de autenticación ni una respuesta de autenticación reutilizable en el servicio legítimo. WebAuthn lo consigue mediante la vinculación criptográfica con el nombre del verificador.

Esta propiedad permanece intacta en Pass-ta-key. El malware no construye una página de phishing mejor. Ya se ejecuta en el dispositivo que el usuario considera un autenticador de confianza.

User Presence y User Verification no son lo mismo

Para comprender los tres ataques hay que distinguir dos señales de WebAuthn:

• User Presence, UP: el usuario realizó una acción de presencia, por ejemplo tocar una llave de seguridad o confirmar un diálogo.
• User Verification, UV: el autenticador verificó localmente al usuario mediante Windows Hello, un PIN o biometría.

La assertion WebAuthn incluye estos resultados como flags en authenticatorData. El servidor no debe confiar únicamente en lo que solicitó al iniciar el login. Si exige userVerification: "required", también debe comprobar en la respuesta que el flag UV esté realmente activado.

Este único punto de control es decisivo. Unit 42 no pudo completar el ataque Pass-ta-key básico contra GitHub porque faltaba la User Verification necesaria. En eBay, el login funcionó inicialmente aunque se había solicitado User Verification. eBay corrigió la validación del servidor tras recibir el aviso.

La diferencia demuestra que una firma criptográficamente correcta no siempre basta para una autenticación multifactor correctamente implementada. La Relying Party debe validar además qué condiciones de seguridad confirmó realmente el autenticador.

Por qué las passkeys sincronizadas amplían el ámbito de confianza

Una passkey vinculada a un dispositivo permanece en un autenticador concreto, como una llave de seguridad física o un autenticador de plataforma protegido localmente. Una passkey sincronizada debe estar disponible en varios dispositivos. Para ello, su material de clave privada debe poder cifrarse, transportarse mediante una infraestructura de sincronización y restaurarse en otros dispositivos autorizados.

No es una diferencia de implementación menor. La sincronización amplía el sistema:

Relying Party
    |
browser and WebAuthn client
    |
local platform authenticator
    |
passkey manager and recovery logic
    |
cloud sync and additional devices

Cada capa adicional necesita sus propias reglas para confianza del dispositivo, onboarding, recuperación, cifrado de claves y revocación.

Por eso NIST trata los autenticadores sincronizables como una categoría específica. Pueden ser adecuados para escenarios hasta Authentication Assurance Level 2. Para AAL3, NIST exige claves no exportables en un entorno protegido por hardware o en un autenticador independiente. Eso no significa que las passkeys sincronizadas sean débiles. Significa que comodidad y portabilidad de claves crean un modelo de assurance diferente.

Pass-ta-key actúa precisamente en este ámbito adicional de confianza.

El alcance exacto de la investigación

Unit 42 señala varios requisitos que muchos titulares no mencionaron:

• Google Password Manager gestiona las passkeys sincronizadas afectadas.
• Chrome se ejecuta en Windows.
• El dispositivo dispone de un TPM.
• Ya se ejecuta malware en el contexto de usuario de la víctima.
• El usuario tiene configurado el entorno de Chrome y Google correspondiente.
• En algunas variantes, el malware debe leer datos locales de Chrome, manipular archivos de estado o inspeccionar la memoria de procesos de Chrome.

No se demostró un ataque universal contra cualquier passkey. Tampoco que un atacante remoto, sin comprometer antes el endpoint, pueda simplemente extraer una clave WebAuthn del TPM.

Por tanto, afirmar que «las passkeys han sido crackeadas» sería falso. La formulación precisa es: Unit 42 demostró tres cadenas de ataque contra los mecanismos de confianza, onboarding y recuperación de passkeys sincronizadas de Google en endpoints Windows comprometidos.

Fase cero: el mapa local de passkeys

Antes de iniciar cualquiera de las tres variantes, el malware lee, según Unit 42, la base de datos local de sincronización de Chrome. Allí se encuentran registros WebauthnCredentialSpecifics que contienen información de la Relying Party, nombres de usuario, Credential IDs y material cifrado de claves privadas.

La ruta indicada en la investigación es:

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

En las pruebas no se necesitaron privilegios elevados para acceder a esos registros. El material de clave privada no aparece directamente en texto claro, pero los metadatos proporcionan al malware una lista de objetivos: para qué servicios existen passkeys, a qué cuentas pertenecen y qué Credential ID debe utilizarse.

Esto ya es relevante para la detección. Un infostealer no necesita adivinar sus objetivos. Puede inventariarlos primero y atacar después cuentas de alto valor de forma selectiva.

Pass-ta-key: una assertion válida sin acción del usuario

La primera variante abusa de la clave de dispositivo con la que Chrome acredita la identidad del equipo Windows ante Google Cloud Authenticator.

Chrome crea para ello una Identity Key respaldada por el TPM. Unit 42 explica que Chrome no guarda la clave privada como una clave convencional en texto claro. La exporta mediante Windows CNG como NCRYPT_OPAQUE_KEY_BLOB. El TPM protege ese blob para que pueda volver a importarse en el mismo TPM físico y utilizarse en operaciones criptográficas.

Tiene sentido desde el punto de vista criptográfico, pero no resuelve automáticamente el problema de autorización. Según la investigación, malware en el contexto normal de usuario pudo leer el wrapped_identity_private_key almacenado u obtenerlo de la memoria de Chrome y llamar a las funciones normales de Windows CNG. El TPM firma porque la solicitud procede técnicamente del dispositivo correcto. No sabe si la API fue invocada por Chrome o por malware.

El flujo simplificado es este:

attacker requests a fresh challenge from the online service
    -> malware on the victim PC uses the TPM-bound identity key
    -> Google Cloud Authenticator accepts the device identity
    -> Cloud Authenticator creates a valid passkey assertion
    -> attacker submits the assertion to the online service

En esta variante no es imprescindible exportar el archivo privado de la passkey. El malware utiliza el dispositivo comprometido y Google Cloud Authenticator como servicio de firma.

El límite natural es el flag UV. La Identity Key confirma la posesión del dispositivo, pero no una comprobación biométrica o de PIN correcta. Un servicio bien implementado que exija User Verification y compruebe el resultado debe rechazar una assertion con UV = 0.

Eso no vuelve inocua la variante. Muchos servicios configuran User Verification como preferred por compatibilidad o experiencia de usuario. Otros la solicitan, pero validan incorrectamente la respuesta. En esos casos, un login concebido como multifactor se reduce en la práctica a un factor: acceso a la identidad del dispositivo.

Silver Pass-ta-key: el atacante registra su propia identidad UV

Silver Pass-ta-key supera ese límite. El atacante no intenta romper Windows Hello ni la biometría de la víctima. Consigue que Cloud Authenticator acepte en adelante una clave propia como prueba válida de User Verification.

El punto de partida es el proceso de re-onboarding. Según la investigación, el malware puede hacer que Cloud Authenticator olvide el estado existente del dispositivo o eliminar localmente el archivo passkey_enclave_state. En la siguiente operación con una passkey, Chrome debe registrar de nuevo el dispositivo.

En Windows, la User Verification Key no siempre se crea en el primer paso. Chrome puede emplear inicialmente el PIN de recuperación de Google Password Manager y establecer el estado uv_key_pending. La clave UV propiamente dicha llega en el siguiente uso de la passkey. Este estado intermedio, optimizado para facilitar el uso, abre una ventana de ataque.

Para prepararlo, la víctima debe completar el proceso inesperado de recuperación o re-onboarding e introducir el PIN de GPM. El malware no necesita robar ese PIN. Aprovecha el estado uv_key_pending resultante. Los inicios de sesión abusivos posteriores pueden realizarse sin interacción adicional y sin que el dispositivo de la víctima esté disponible.

El atacante genera un par de claves en su propio entorno y envía la clave pública como nueva UV Key. Unit 42 constató que Google Cloud Authenticator no validaba si esa nueva clave procedía realmente de hardware de confianza. El sistema almacenaba la clave del atacante junto a la identidad legítima del dispositivo.

Desde ese momento, el atacante puede firmar por sí mismo las solicitudes con su clave privada. Cloud Authenticator las trata como una verificación local del usuario y genera assertions con el flag UV activado. El PC de la víctima ya no necesita estar online para los logins posteriores.

El issue público de Chromium denomina este comportamiento «GPM Passkeys Are Vulnerable to User Verification Key Abuse». En el momento de mi comprobación figuraba como WAI. Al margen de su clasificación interna, el caso demuestra una regla arquitectónica esencial: un proceso de recuperación u onboarding que vincula nuevas claves de confianza es en sí mismo un evento de autenticación crítico.

Golden Pass-ta-key: la sincronización cloud se convierte en material de clave exportable

Golden Pass-ta-key es la variante más grave. Su objetivo es el Security Domain Secret, o SDS. Este secreto de 32 bytes protege las claves privadas sincronizadas de las passkeys de una cuenta de Google Password Manager.

La promesa arquitectónica, simplificada, es que el cliente solo posee un wrapped_secret cifrado. Cloud Authenticator lo descifra con una clave específica del dispositivo. Ni siquiera el malware del cliente debería obtener así las claves privadas de las passkeys.

Sin embargo, durante el onboarding y la recuperación, la infraestructura de sincronización debe reincorporar dispositivos a la Security Domain. Unit 42 descubrió que Chrome recibe entonces el SDS en una forma accesible para el cliente. Al principio incluso aparecía en el log de diagnóstico FIDO de Chrome. Google eliminó esa salida tras la notificación, pero durante el proceso el SDS sigue llegando a la memoria del proceso de Chrome.

Golden Pass-ta-key tampoco permite volcar la memoria arbitrariamente en cualquier momento. El malware debe forzar primero la ruta crítica de onboarding o recuperación y acertar el momento en que el SDS está presente en el proceso de Chrome. Eso aumenta la dificultad, pero no reduce el alcance del secreto una vez extraído.

La cadena combina varios pasos:

1. El malware fuerza un nuevo onboarding.
2. Espera a que se cree o modifique el estado local del enclave.
3. Lee la memoria del proceso de Chrome en el momento adecuado y busca el SDS.
4. Combina el SDS con los registros de sincronización leídos anteriormente.
5. Descifra las claves privadas de passkeys que contienen.
6. Un autenticador propio e independiente del dispositivo de la víctima puede generar después assertions válidas.

Aquí reside la diferencia cualitativa frente a una cookie de sesión robada. Una sesión puede caducar o revocarse en el servidor. Golden Pass-ta-key pretende exportar las claves privadas de todas las passkeys ya sincronizadas. Unit 42 afirma además que el mismo SDS protege futuras passkeys sincronizadas y que, en la arquitectura estudiada, no existía una opción visible para rotarlo o revocarlo.

Esta afirmación describe el estado de la implementación de Google analizada. No demuestra que todos los proveedores utilicen la misma arquitectura de clave maestra ni que Google no pueda modificarla.

Por qué el malware local no vuelve irrelevante el ataque

Quien ya puede ejecutar malware arbitrario en el contexto de usuario de un PC autenticado dispone de vías más sencillas. Puede robar cookies de sesión, leer contenidos del navegador, manipular transacciones, exfiltrar archivos o actuar directamente dentro de la cuenta activa. Ningún método de autenticación puede confiar sin límites en un cliente totalmente comprometido.

La clase de ataque tampoco es nueva. Robar secretos o sesiones activas de un gestor de contraseñas y un navegador comprometidos forma parte desde hace años del repertorio de los infostealers. Pass-ta-key no convierte una intrusión previa en el endpoint en un ataque remoto mágico.

Pero descartarlo como irrelevante también sería un error. La investigación aporta hallazgos concretos y específicos de la implementación:

• Un proceso sin privilegios pudo utilizar una clave de dispositivo de Chrome vinculada al TPM para firmar.
• La frontera entre posesión del dispositivo y verificación del usuario dependía de que las Relying Parties evaluaran correctamente el flag UV.
• El estado de re-onboarding permitió registrar una UV Key controlada por el atacante.
• El secreto central de sincronización apareció primero en un log y siguió siendo accesible en memoria según la investigación.
• La ruta más grave hizo reutilizables las claves privadas sincronizadas fuera del dispositivo original.
• En las passkeys sincronizadas suele faltar el contador de firmas clásico como señal fiable de clonación, porque varios dispositivos legítimos comparten la misma credencial.

«Endpoint comprometido» es un requisito, no una descripción completa del daño. En Incident Response importa mucho si el atacante robó solo una sesión temporal o si posee material de clave privada reutilizable a largo plazo para numerosos servicios.

Pass-ta-key es solo una parte de la nueva superficie de ataque

Pass-ta-key no apareció de forma aislada. Investigaciones de 2025 y 2026 muestran varias vías para reducir la protección de una passkey sin romper matemáticamente su clave privada.

El abuso de sincronización y recuperación de Pass-ta-key requiere malware activo en el endpoint Windows. Pass-the-Passkey combina el acceso a una assertion registrada con una vulnerabilidad de replay en el servidor. Para un downgrade FIDO basta que permanezca habilitado un método alternativo susceptible de phishing, mientras que Passkeys Pwned necesita una extensión maliciosa o ejecución de scripts en el contexto del navegador. Por último, los infostealers no atacan la passkey, sino la sesión ya autenticada en un navegador o endpoint comprometido.

Ninguna de estas vías rompe la criptografía de clave pública. Todas atacan una capa de confianza que rodea WebAuthn: sincronización y recuperación, validación del servidor, navegador o sesión posterior al login.

No es una distinción semántica. Una ruptura del protocolo cuestionaría todas las implementaciones conformes. Estos casos requieren contramedidas distintas en endpoint, navegador, identidad y servidor.

Pass-the-Passkey: cuando una assertion válida puede reutilizarse

SpecterOps identificó para Black Hat USA 2026 tres vulnerabilidades en Windows 11 y Microsoft Entra ID, además de más de 20 técnicas derivadas. La cadena principal comenzaba en un lugar inesperado: Windows registraba assertions WebAuthn completas en el Event Log Microsoft-Windows-WebAuthN/Operational.

Una assertion contiene, entre otros elementos, Credential ID, challenge, datos del autenticador y firma. No es una clave privada y, con un verifier correcto, solo debería funcionar una vez y en la sesión de autenticación correspondiente. SpecterOps comprobó que Entra ID aceptaba de nuevo assertions registradas dentro de una ventana temporal limitada. Se combinaron dos fallos:

Windows logs a complete assertion
    -> an attacker reads it
    -> the verifier does not bind the challenge and assertion tightly enough to the session
    -> the same signed response is accepted again

La parte de Windows recibió la referencia CVE-2026-34348. Microsoft publicó el 14 de julio de 2026 una actualización que reduce la firma registrada a unos pocos bytes y elimina así la fuente del replay. Además, se introdujo en el servidor la comprobación de contadores de firma para determinadas llaves de seguridad FIDO2. Sin embargo, los contadores no son una protección universal. Algunas credenciales de plataforma y sincronizadas devuelven siempre cero o comparten estado entre varios dispositivos.

La enseñanza va más allá de esa cadena ya interrumpida. Las assertions WebAuthn no deben aparecer en logs de diagnóstico ni de eventos. Los challenges deben ser aleatorios, breves, de un solo uso y estar vinculados a la sesión concreta. Una firma válida no demuestra por sí sola que todo el flujo de login fuera correcto.

Otra técnica afecta al Parent-Window-Handle de la API WebAuthn de Windows. Un proceso local puede colocar un diálogo de passkey real de forma que parezca pertenecer a una aplicación fiable, como el navegador o el cliente de correo. La interfaz del sistema es auténtica, pero el contexto que la activó puede ser engañoso. Por eso los usuarios deben tratar solicitudes inesperadas de passkeys y Windows Hello como notificaciones MFA push inesperadas.

El fallback más débil determina el nivel de seguridad real

Proofpoint demostró en 2025 un downgrade FIDO contra Microsoft Entra ID. Un flujo Evilginx modificado se presentaba como un navegador sin soporte FIDO. La plataforma ofrecía entonces métodos alternativos de acceso. Si la víctima elegía SMS, OTP u otro método susceptible de phishing, el flujo Adversary-in-the-Middle podía capturar credenciales y sesión.

El ataque no elude el Origin Binding. Evita que la ceremonia WebAuthn llegue a empezar. Solo funciona si la cuenta permite un método más débil junto a la passkey. No se ha documentado explotación real de este downgrade.

Para las empresas la regla es incómoda, pero clara: una política no es resistente al phishing solo porque se haya registrado una passkey. Lo es cuando el login para ese nivel de protección ya no admite alternativas susceptibles de phishing. Recuperación y restablecimientos del helpdesk deben formar parte de la misma evaluación.

El navegador forma parte del modelo de seguridad

SquareX mostró con Passkeys Pwned cómo una extensión maliciosa o scripts ejecutados en el contexto del navegador pueden influir en navigator.credentials.create() y navigator.credentials.get(). El registro es especialmente sensible: si el atacante introduce su propio material de clave en el momento adecuado, el usuario puede ver un diálogo biométrico real mientras se vincula en segundo plano una credencial controlada por el atacante.

La investigación procede de un proveedor de seguridad y no debe presentarse como un exploit universal del navegador. La condición previa ya es considerable: la extensión o el contexto de script debe poder intervenir en la ruta WebAuthn. Aun así, la lección arquitectónica es válida. Extensiones, Content Scripts y funciones legítimas de proxy WebAuthn forman parte de la Trusted Computing Base. En entornos gestionados, las allowlists de extensiones y el control de APIs privilegiadas protegen la identidad, no solo el navegador.

Las passkeys protegen el login, no necesariamente la sesión posterior

Después de autenticarse, el servicio suele continuar con una cookie o un token de sesión. Si un infostealer roba ese artefacto del navegador y el servidor acepta reutilizarlo desde otro dispositivo, el atacante no necesita contraseña ni passkey. Ataca una sesión ya autenticada.

Hoy es una vía más práctica que muchas pruebas de concepto de investigación. Las passkeys reducen enormemente la superficie antes y durante el login, pero no sustituyen el almacenamiento seguro de tokens, una duración de sesión corta y basada en riesgo, la reautenticación para acciones críticas, la revocación ni, cuando sea posible, la vinculación criptográfica de sesiones valiosas al dispositivo.

Decir que «se eludió MFA» suele ser impreciso en un robo de sesión. MFA se completó correctamente. Lo robado fue su resultado posterior.

PoisonSeed demuestra la rapidez con que la investigación puede convertirse en hype

En julio de 2025, Expel comunicó inicialmente un supuesto ataque contra la autenticación entre dispositivos con passkeys. El atacante presuntamente reenviaba a la víctima un código QR legítimo mediante una página de phishing para apropiarse del login remoto. Días después, Expel retiró públicamente la afirmación principal y se disculpó.

El análisis posterior mostró que no se había superado la comprobación de proximidad local prevista para Cross-Device Authentication. Sin la proximidad necesaria, el flujo expiró, todos los desafíos MFA fallaron y el atacante no obtuvo acceso.

El caso es útil para el debate actual. No toda combinación plausible de código QR, phishing y passkey constituye un bypass FIDO funcional. Una buena comunicación de seguridad debe distinguir entre una toma de cuenta observada, una prueba de concepto reproducible, un ataque teórico y una hipótesis refutada.

Mi valoración de seguridad

El alcance técnico de Pass-ta-key es limitado. La cadena se demostró contra Google Password Manager en Chrome sobre Windows con TPM. La probabilidad de entrada es media o baja, porque el malware ya debe ejecutarse localmente y, según la variante, manipular estados o memoria de procesos.

El impacto posible es alto o muy alto. Un ataque exitoso puede provocar una toma de cuenta, acceso remoto persistente o extracción de varias claves privadas. El riesgo para el protocolo es bajo porque no se rompen WebAuthn, Origin Binding ni la criptografía de clave pública.

Para un usuario normal, una passkey sincronizada sigue siendo por regla general más segura que una contraseña con SMS o TOTP. Elimina de muchos escenarios reales el phishing, Credential Stuffing y el robo de contraseñas reutilizables.

Para administradores privilegiados, autorizaciones financieras, accesos a producción o sistemas muy regulados, esa afirmación general no basta. La organización debe decidir si una passkey sincronizada alcanza el nivel de assurance requerido. Una clave de plataforma vinculada al dispositivo o una llave física FIDO2 independiente puede ser el límite más apropiado.

No es un rechazo de las passkeys sincronizadas. Es una arquitectura de seguridad graduada.

Qué deben comprobar los operadores de servicios web

La lección principal para las Relying Parties no es exótica: deben validar WebAuthn correctamente.

Los servidores deberían:

• establecer userVerification: "required" cuando el caso de uso requiera verificación local real,
• comprobar obligatoriamente el flag UV devuelto en authenticatorData,
• validar por completo challenge, Origin, Relying Party ID y firma,
• generar cada challenge de forma aleatoria, limitar su vigencia, aceptarlo una sola vez y vincularlo a la sesión,
• evitar que assertions completas, firmas u otros artefactos reutilizables aparezcan en logs,
• registrar el alta y la eliminación de passkeys y la recuperación de cuenta como eventos de alto riesgo,
• permitir nuevos autenticadores en cuentas privilegiadas solo tras una reautenticación fuerte,
• registrar cuando sea posible el origen y las propiedades del autenticador,
• considerar attestation y autenticadores gestionados en entornos de alta seguridad,
• incorporar cambios anómalos de dispositivo, geolocalización y nuevas vinculaciones de passkeys a la telemetría de identidad,
• revocar sesiones tras cambios de riesgo y reautenticar acciones críticas,
• usar sesiones vinculadas al dispositivo cuando plataforma y aplicación lo soporten de forma fiable.

Una biblioteca WebAuthn consolidada reduce el riesgo de implementaciones propias incompletas, pero no exime de revisar su configuración. El caso de eBay muestra cómo un solo flag ignorado puede rebajar el nivel previsto. Pass-the-Passkey demuestra además que una firma correcta pierde valor si challenge y sesión no están correctamente vinculados.

Qué deberían cambiar las empresas al desplegar passkeys

Los proyectos de passkeys suelen planificarse como iniciativas IAM. Pass-ta-key demuestra que también son proyectos de endpoint, navegador y recuperación.

Las passkeys sincronizadas siguen siendo adecuadas para cuentas habituales de la plantilla. Reducen la carga del helpdesk y ofrecen una protección muy eficaz frente al phishing. En roles privilegiados, la política debe diferenciar claramente según el nivel de protección.

Las cuentas normales pueden utilizar passkeys sincronizadas en dispositivos gestionados junto con protección de endpoint y Conditional Access. Para cuentas sensibles son apropiados autenticadores de plataforma gestionados o entornos de sincronización restringidos y mejor vinculados al dispositivo. Las cuentas de administrador, Break Glass y otras de alto valor deberían usar llaves físicas FIDO2 separadas, recuperación estrictamente controlada y ninguna sincronización cloud no controlada.

Además, las empresas deberían:

• mantener Chrome y Windows actualizados,
• comprobar el nivel de parcheo de Windows frente a CVE-2026-34348,
• permitir o limitar conscientemente mediante Enterprise Policies el almacenamiento de passkeys en el gestor integrado del navegador,
• controlar extensiones con allowlists y supervisar funciones privilegiadas de proxy WebAuthn,
• aplicar EDR y Application Control también a procesos de usuario,
• vigilar accesos a bases de datos de sincronización del navegador y volcados de memoria de Chrome,
• investigar la eliminación o recreación inesperada de passkey_enclave_state,
• tratar solicitudes repetidas o inesperadas del PIN de recuperación de Google Password Manager como una señal de alerta,
• probar contra abusos los procesos de pérdida de dispositivo y recuperación de cuenta,
• eliminar fallbacks susceptibles de phishing para cuentas privilegiadas o excluirlos mediante una Authentication Strength Policy,
• investigar diálogos inesperados, nuevos registros de credenciales y usos WebAuthn desde procesos inusuales,
• inventariar qué servicios importantes utilizan credenciales sincronizadas y cuáles vinculadas al dispositivo.

El punto organizativo decisivo es que Endpoint Detection no es una partida independiente del proyecto de passkeys. Si el autenticador vive en el navegador y el cliente, la seguridad del endpoint forma parte directa del modelo de autenticación.

Qué deben hacer ahora los usuarios

No hay razón objetiva para borrar preventivamente todas las passkeys y volver a contraseñas más débiles.

Sí tiene sentido:

• actualizar Chrome y Windows con rapidez,
• instalar únicamente software y extensiones de navegador de confianza,
• mantener activos la protección del dispositivo, Windows Hello y el antimalware,
• no confirmar diálogos inesperados de passkeys o Windows Hello,
• no aprobar rutinariamente solicitudes inesperadas de PIN de recuperación o re-onboarding,
• revisar en Google Password Manager y servicios importantes los dispositivos y passkeys registrados,
• considerar una llave física independiente para cuentas de especial valor,
• aislar e investigar un endpoint sospechoso en lugar de seguir utilizándolo.

Ante indicios concretos de malware, estados de Chrome manipulados o un volcado de memoria, hay que asumir un posible robo de credenciales y sesiones. Cambiar la contraseña no basta. Es necesario reconstruir o limpiar de forma fiable el endpoint, revocar sesiones activas, revisar métodos de recuperación, eliminar passkeys desconocidas y registrar de nuevo autenticadores fiables.

Un posible incidente Golden Pass-ta-key exige especial cautela. La investigación publicada no describe una rotación sencilla del SDS para usuarios. No debe afirmarse que cambiar el PIN o recrear una sola passkey resuelva el problema con garantías. Para cuentas valiosas, tras limpiar el endpoint registraría nuevas credenciales vinculadas al dispositivo, eliminaría las antiguas credenciales sincronizadas e implicaría al proveedor o al equipo de Incident Response en la recuperación.

La lección esencial

Las passkeys no son un escudo contra cualquier compromiso. Resuelven un problema concreto y enorme: las personas dejan de entregar un secreto reutilizable a un servidor o a un sitio web posiblemente falso.

Pass-ta-key muestra la siguiente capa. Cuando las claves privadas se sincronizan cómodamente entre dispositivos, aparece una infraestructura de cifrado de claves, confianza del dispositivo y recuperación. Esa infraestructura puede contener errores aunque el protocolo WebAuthn subyacente sea correcto.

Sería incorrecto declarar fracasadas las passkeys. También lo sería trivializar cualquier ataque posterior a una infección local.

Mi valoración es clara: hay que seguir desplegando passkeys, pero formular con precisión sus garantías. Las passkeys sincronizadas son excelentes contra el phishing. Las llaves físicas vinculadas al dispositivo establecen una frontera más fuerte para cuentas de alto valor. Y ningún autenticador sustituye un endpoint limpio, procesos de recuperación controlados y verificaciones correctas en el servidor.

Las passkeys han cerrado mucho mejor la puerta al phishing. Pass-ta-key recuerda que un atacante que ya está dentro de la casa necesita otra defensa.

Hasta la próxima,
Joe

Preguntas frecuentes