No, la nueva investigación de la Unidad 42 no mostró que el cifrado de las claves de acceso estuviera roto o que ya no fueran resistentes al phishing. El trabajo reveló tres formas de abusar de la implementación de claves de acceso sincronizadas por Google Password Manager cuando ya se está ejecutando malware en el ordenador de la víctima. El estudio se centró en Chrome para Windows, en dispositivos con Trusted Platform Module (TPM).
Esta diferencia es importante. Las claves de acceso siguen utilizando criptografía de clave pública y están vinculadas al sitio web o la aplicación para la que fueron creadas. Esta vinculación impide el uso normal de la credencial en un sitio de phishing que imita la dirección legítima. Google y FIDO Alliance continúan describiendo esta propiedad como resistencia al phishing.
Las preguntas de la investigación son otra capa: qué sucede cuando el mismo dispositivo que almacena, sincroniza o autoriza el uso de la clave de acceso ya está comprometido.
Lo que encontró la Unidad 42
La Unidad 42 presentó tres clases de ataque, llamados Pass-ta-key, Silver Pass-ta-key y Golden Pass-ta-key. En todos los casos demostrados, el punto de partida es el malware presente en el ordenador de la víctima; Los investigadores afirman explícitamente que los ataques no rompen el cifrado subyacente de las claves de acceso.
- Clave de acceso: el malware sin privilegios administrativos puede abusar de la identidad del dispositivo utilizada por Chrome para solicitar al autenticador en la nube de Google una respuesta criptográficamente válida. El ataque no requiere que la víctima desbloquee el ordenador ni confirme la operación en ese momento. Suele fallar cuando el servicio lo requiere y verifica correctamente el indicador de que el usuario ha sido autenticado localmente.
- Silver Pass-ta-key: la investigación mostró una manera de manipular el proceso de reinscripción del dispositivo y registrar una clave de verificación controlada por el atacante. Según la Unidad 42, el autenticador de la nube no verificó adecuadamente que esta nueva clave proviniera de hardware confiable. Después de este registro, el atacante podría producir autenticaciones tratadas como verificadas incluso desde otro sistema.
- Clave de paso dorada: el escenario más impactante involucra el secreto maestro del dominio de seguridad, o SDS, que se utiliza para proteger las claves de acceso sincronizadas de la cuenta. La Unidad 42 inicialmente encontró este secreto en texto legible en los registros internos de Chrome. Google eliminó SDS de estos registros después del informe, pero los investigadores dicen que todavía pasa temporalmente por la memoria de proceso de Chrome durante ciertas operaciones de registro o recuperación. En este escenario, el malware presente en el terminal podría intentar extraer el secreto y utilizarlo para recuperar las claves privadas de las claves de acceso sincronizadas.
El último escenario también expone un problema de persistencia señalado por los investigadores: según la Unidad 42, la implementación analizada no ofrece un mecanismo para rotar o revocar la SDS, lo que protege tanto las credenciales existentes como las nuevas claves de acceso sincronizadas posteriormente.
Por qué esto no equivale a “romper claves”
La resistencia al phishing resuelve un problema específico. En la autenticación WebAuthn normal, la clave de acceso está vinculada a la identidad del servicio, y el navegador y el sistema operativo evitan que una página fraudulenta simplemente solicite la misma credencial y la reutilice.. El servidor también guarda la clave pública, no un secreto equivalente a la clave privada del usuario.
Los ataques de la Unidad 42 comienzan después de que ya se ha superado una barrera diferente: el atacante ha logrado ejecutar malware en el ordenador de la víctima.
Esto no hace que el resultado sea irrelevante. Por el contrario, muestra que reemplazar las contraseñas con claves de acceso no elimina la necesidad de proteger los puntos finales, los navegadores, los procesos de recuperación y los mecanismos de sincronización. Pero esto es diferente a descubrir una técnica remota capaz de suplantar una clave de acceso o derivar su clave privada a partir de la clave pública almacenada en el sitio web.
La propia Unidad 42 concluye que las claves de acceso siguen siendo una mejora significativa con respecto a las contraseñas porque eliminan los secretos compartidos y reducen clases enteras de ataques. El trabajo llama la atención sobre las nuevas superficies creadas por implementaciones sincronizadas y los sistemas que deciden cuándo confiar en un dispositivo.
El primer ataque también demostró que el sitio importa
Un detalle del experimento ayuda a comprender por qué la clave de acceso no es solo un problema del navegador o del administrador de credenciales.
En la primera técnica, la respuesta producida por el autenticador contiene un indicador llamado Usuario Verificado o UV, que informa si se ha producido la verificación local requerida, como PIN o datos biométricos. La Unidad 42 intentó el ataque contra GitHub y no pudo autenticarse porque el servicio verificó este indicador. Sin embargo, en eBay los investigadores no pudieron completar el inicio de sesión durante las pruebas porque la validación no se aplicaba correctamente. eBay solucionó el problema después de recibir el informe.
Esto muestra que la máxima seguridad también depende de quién recibe la autenticación. La recomendación de la Unidad 42 para los servicios que utilizan claves de acceso es exigir la verificación del usuario cuando corresponda y validar de manera efectiva el indicador UV recibido, en lugar de simplemente solicitar la verificación al comienzo del flujo.
Qué cambios para aquellos que ya usan claves de acceso
Para la mayoría de las personas, la investigación no es un motivo para volver a las contraseñas. Las contraseñas siguen estando sujetas a phishing, reutilización, filtraciones y robo de credenciales, mientras que las claves de acceso se diseñaron precisamente para eliminar varias de estas rutas. La documentación actual de Google continúa clasificando las claves de acceso como una alternativa antiphishing más segura y recomienda no crearlas en dispositivos compartidos.
Sin embargo, el resultado refuerza que la seguridad de la cuenta no termina en el método de inicio de sesión. El sistema operativo y el navegador deben permanecer actualizados, y los signos de malware comprometido deben tratarse como un problema de seguridad para toda la máquina, no solo para la contraseña o la clave de acceso.
Unit 42 también recomienda prestar atención a solicitudes de PIN de recuperación de Google Password Manager repetidas o inesperadas. Este tipo de solicitud suele estar asociado con el registro o la recuperación del dispositivo, y las investigaciones han demostrado que forzar estos flujos era parte de los escenarios Plata y Oro.
Cualquier persona que sospeche que una computadora ha sido comprometida debe priorizar contener y borrar el dispositivo y revisar el acceso, las sesiones, los dispositivos y las credenciales asociadas con la cuenta desde un entorno confiable. Google te permite comprobar y eliminar claves de acceso y dispositivos vinculados a tu cuenta de Google.
En el escenario específico de posible exposición a SDS descrito por la Unidad 42, la situación requiere precaución adicional: los investigadores afirman que la implementación analizada no proporciona rotación o revocación de este secreto maestro. Por lo tanto, no es prudente suponer que simplemente cambiar una contraseña resolvería una exposición de esta naturaleza.
¿Se han solucionado ya los fallos?
Hay correcciones parciales confirmadas en las fuentes consultadas. eBay arregló la validación del indicador de verificación del usuario después de recibir el informe. Google también eliminó Security Domain Secret de los registros internos de Chrome luego de la divulgación responsable del problema.
La Unidad 42, sin embargo, establece en su artículo que la SDS aún se envía al cliente y puede permanecer accesible temporalmente en la memoria de proceso de Chrome. El 3 de agosto de 2026, BleepingComputer informó que se había comunicado con Google para ver si se resolvieron todos los escenarios, pero no había recibido una respuesta en el momento de la publicación.
Hasta el 9 de agosto de 2026, las fuentes públicas consultadas para este artículo no nos permiten afirmar que todas las condiciones descritas por la investigación hayan sido eliminadas. Los informes públicos de Google vinculados por Unit 42 tampoco exponen sus detalles sin autenticación, lo que limita la confirmación independiente del estado de cada corrección.
¿Siguen valiendo la pena las claves de acceso?
El resultado de la investigación apunta más a un cambio en el modelo de amenaza que al fallo de las claves de acceso.
Si bien las contraseñas brindan a los atacantes un secreto que puede ser robado mediante phishing, reutilizado o probado en otros servicios, las claves de acceso eliminan este secreto compartido y vinculan la autenticación al servicio legítimo.
El nuevo destino se convierte en el entorno alrededor de la credencial: dispositivo, navegador, administrador de claves de acceso, sincronización, recuperación y validación realizada por el servicio.
La lectura práctica, por lo tanto, no es “se rompieron las claves”. Sí: las claves de acceso dificultan los ataques tradicionales, pero no hacen que una computadora que ya está bajo control de malware sea segura. La investigación de la Unidad 42 muestra dónde aún es necesario reforzar las implementaciones sincronizadas para que las garantías del protocolo también sobrevivan a este escenario.
