La arquitectura de clave de acceso oculta de Google Authenticator podría abrir nuevas rutas de ataque sin contraseña

Diseñado para reemplazar las contraseñas tradicionales con claves criptográficas vinculadas a dispositivos físicos, prometía un futuro en el que las credenciales robadas ya no podrían desbloquear las cuentas de los usuarios. Pero un examen detenido de cómo Google ha construido realmente su ecosistema de claves de acceso revela algo mucho más complejo que la imagen limpia y segura que normalmente proyecta "sin contraseña".

Debajo de cada inicio de sesión con contraseña impulsado por Google Password Manager, un componente oculto de la nube realiza silenciosamente operaciones criptográficas confidenciales y puede estar creando nuevas rutas de ataque que nunca se han discutido públicamente. El sistema de claves de acceso de Google no funciona como un autenticador de hardware convencional bloqueado en un solo dispositivo. Este dominio funciona como un autenticador basado en la nube responsable de generar claves de acceso, manejar solicitudes de autenticación y mantener las credenciales sincronizadas en todos los dispositivos registrados de un usuario. En enero de 2026, casi ninguna información pública describía el papel de este dominio en la autenticación de claves de acceso, a pesar de que impulsaba silenciosamente los inicios de sesión a escala en todo el mundo.  Una búsqueda de la URL del Autenticador de Google arroja solo unos pocos resultados no informativos (Fuente: Unidad 42).

Dentro del flujo de autenticación del Cloud Authenticator La comunicación entre Chrome y el autenticador de la nube está protegida por Noise Protocol Framework, utilizando la variante de protocolo de enlace Noise_NK_P256_AESGCM_SHA256.  Flujo de comunicación segura del autenticador de Chrome-nube (Fuente: Unidad 42) Chrome abre una conexión WebSocket a wss[:]//enclave.ua5v[.]com/enclave, realiza un intercambio de claves Diffie-Hellman para establecer una clave de sesión compartida y luego firma cada solicitud posterior con una clave de dispositivo respaldada por TPM.  Inicialización de WebSocket (Fuente: Unidad 42) Durante un inicio de sesión con clave de acceso, Chrome envía el comando passkeys/assert junto con el ID del dispositivo y la SDS empaquetada. Las organizaciones y las personas que dependen de claves de acceso sincronizadas a través de GPM deben monitorear de cerca sus cuentas de Google para detectar inscripciones inesperadas de dispositivos, auditar periódicamente los registros de autenticación para detectar patrones de acceso inusuales y considerar el uso de claves de seguridad de hardware compatibles con FIDO2 para cuentas privilegiadas o de alta sensibilidad en lugar de claves de acceso sincronizadas en la nube.

Consultar publicación original ↗