Las passkeys no son magia: qué cambia realmente Pass-ta-key

La discusión de agosto sobre Pass-ta-key no debería llevar a abandonar las passkeys. Debería llevar a usarlas con un modelo de amenaza menos ingenuo. Unit 42 analizó ataques contra passkeys sincronizadas de Google Password Manager en Chrome para Windows. Ars Technica añadió el matiz necesario: no es una prueba de que las passkeys hayan muerto, sino una demostración de que “resistente al phishing” no significa “inmune a un equipo infectado”.

Qué pasó y qué no significa

El trabajo de Unit 42 se centra en un entorno concreto: Google Password Manager, Chrome en Windows, un cloud authenticator y confianza de dispositivo apoyada por TPM. Los investigadores nombran tres variantes, Pass-ta-key, Silver Pass-ta-key y Golden Pass-ta-key. El detalle clave es que todas empiezan con malware ya presente en el dispositivo de la víctima. Eso cambia la lectura. No hablamos de una página falsa que roba una passkey como si fuera una contraseña, ni de una ruptura general del estándar WebAuthn.

La conclusión correcta es más precisa. En ese entorno, código local malicioso puede abusar del estado del navegador, del onboarding de dispositivos, de flujos de recuperación y de decisiones de user verification alrededor de passkeys sincronizadas. En algunas configuraciones eso puede permitir acceso sin una nueva acción visible del usuario, eludir una verificación esperada o extraer material sincronizado útil para el atacante. Es importante para implementadores y equipos de seguridad, pero no invalida la protección contra phishing de una passkey bien usada.

Ars ayuda porque frena el pánico sin minimizar. Si el endpoint ya está comprometido y la sesión del usuario es de confianza, el atacante puede ir tras cookies, tokens, perfiles de navegador, bóvedas de contraseñas, archivos, notificaciones o pantallas de recuperación. Las passkeys fueron diseñadas para reemplazar secretos compartidos y resistir sitios falsos. No fueron diseñadas para sustituir antivirus, EDR, aislamiento del sistema operativo y respuesta a incidentes.

Cómo protege una passkey

Una passkey es una credencial FIDO/WebAuthn basada en criptografía de clave pública. El authenticator crea un par de claves para un relying party concreto. El servicio guarda la clave pública. La privada queda bajo control del authenticator o del proveedor de passkeys. Durante el inicio de sesión, el servicio envía un challenge, el authenticator firma datos vinculados al origen correcto, y el navegador devuelve una assertion. Según la política, el usuario desbloquea el dispositivo, usa biometría, PIN o toca una llave.

Eso cambia la economía del ataque. Una página falsa no recibe una contraseña reutilizable. Una base de datos filtrada no entrega hashes que puedan probarse en otros sitios. El credential stuffing pierde fuerza porque el secreto no se comparte entre servicios. Por eso FIDO y W3C hablan de sign-in resistente al phishing: la respuesta queda unida al origen legítimo, no a la imitación visual de un formulario.

Pero resistente al phishing no es resistente a malware. Significa que un sitio remoto de engaño no debería obtener un secreto reutilizable. No significa que un portátil infectado no pueda actuar dentro del mismo perfil de navegador, invocar flujos ya confiables, esperar el desbloqueo del usuario, leer estado local mal protegido o abusar de sesiones activas. Las promesas de seguridad tienen bordes. Las passkeys cubren un borde amplio, no todo el mapa.

Lo que mostró Unit 42

El artículo de marzo de Unit 42 explicaba mecanismos de Google Cloud Authenticator para passkeys sincronizadas. El de agosto mostró cómo Chrome en Windows, datos locales de sincronización, TPM y confianza de dispositivo pueden interactuar de formas que el usuario no ve. El alcance declarado importa: Google Password Manager en Chrome para Windows con TPM, divulgación responsable y malware previo en el equipo.

La primera lección es sobre confianza de dispositivo. Si el atacante ejecuta código donde ya viven el navegador y la cuenta de Google, puede intentar hacer que ciertos pasos parezcan venir de un contexto legítimo. La segunda es sobre user verification. WebAuthn permite required, preferred o discouraged; para cuentas sensibles, dejarlo en preferred puede no ser suficiente. La tercera es sobre sincronización. Las passkeys sincronizadas son útiles porque sobreviven a la pérdida del dispositivo y reducen el retorno a contraseñas débiles, pero recovery y backup pasan a formar parte de la superficie de ataque.

La respuesta no es prohibir sincronización a todo el mundo. Para consumidores normales, una passkey sincronizada suele ser mucho mejor que contraseña más SMS. Para administradores, personal financiero, mantenedores de código y directivos, la respuesta puede ser una llave de seguridad física, un dispositivo gestionado, acceso condicional y políticas de inscripción estrictas.

Por qué siguen importando

El phishing de contraseñas sigue siendo masivo. La reutilización de contraseñas convierte una filtración en varias tomas de cuenta. Los códigos de un solo uso pueden ser capturados por kits adversary-in-the-middle. Las passkeys reducen directamente esos problemas. La reacción sensata ante los titulares de agosto es mantenerlas activadas y añadir higiene de dispositivo, no volver a una contraseña memorizada y reutilizada.

También hay que pedir más a los servicios. WebAuthn no debe tratarse como una pegatina de marketing. El challenge debe ser único, impredecible, de vida corta y vinculado a la sesión. El servidor debe verificar origin, relying party ID, firma y replay. User verification debe ser obligatoria cuando la cuenta o la acción lo requiera. Registrar una nueva passkey debe exigir una sesión reciente, notificación al usuario y controles fuertes sobre recuperación.

Google explica que las passkeys son una alternativa sencilla y segura a las contraseñas, y que no se comparten o escriben como una contraseña. Eso es correcto como explicación de usuario, pero necesita contexto. Una passkey sincronizada vive dentro de un ecosistema con nube cifrada, onboarding, recovery y estado local del navegador. El usuario no entrega una clave privada a una página falsa; un malware en el endpoint puede atacar el sistema que la rodea.

Guía para usuarios

Mantén passkeys en las cuentas importantes. Usa bloqueo de pantalla fuerte en cada dispositivo que pueda aprobar inicios de sesión. Elimina teléfonos, portátiles y navegadores antiguos desde las páginas de seguridad. Revisa correo y teléfono de recuperación, porque la recuperación suele ser la puerta débil. Evita computadoras compartidas para correo principal, banca, cuentas de desarrollador o consola cloud, aunque la cuenta tenga passkey.

Sé estricto con extensiones del navegador. Una extensión con permisos amplios está cerca de páginas, prompts y sesiones. Mantén sistema operativo y navegador al día. Si un equipo tuvo malware, trata la limpieza como un incidente de identidad: revoca sesiones, revisa passkeys añadidas, elimina dispositivos desconocidos, comprueba reglas de correo y permisos OAuth. Limpiar el archivo malicioso y no revisar la cuenta deja media puerta abierta.

Para cuentas de alto valor, añade una llave de seguridad física y guarda una segunda llave de respaldo. No es tan cómoda como la sincronización, pero reduce la dependencia del estado común del escritorio. Tampoco es magia: recuperación, soporte y seguridad posterior al inicio de sesión siguen contando.

Guía para organizaciones

Una empresa debe clasificar antes de desplegar. ¿Quién solo necesita protección contra phishing masivo? ¿Quién puede cambiar políticas de identidad, pagar facturas, desplegar producción o leer datos regulados? ¿Qué dispositivos están gestionados y monitorizados? ¿Qué proveedores de passkeys se permiten? ¿Dónde se aceptan passkeys sincronizadas y dónde se requieren credenciales atadas a dispositivo o llaves hardware?

Para cuentas de bajo riesgo, passkeys sincronizadas pueden ser una gran mejora frente a contraseñas y SMS. Para administradores, la política puede exigir autenticación resistente al phishing con hardware keys, dispositivos gestionados, cumplimiento del endpoint, estaciones privilegiadas y elevación temporal. Conviene separar la línea Unit 42 sobre Google/Chrome/Windows de la línea SpecterOps y Microsoft Entra sobre WebAuthn, Windows 11, logging de assertions y validación de replay. No son el mismo fallo; comparten la lección de que los detalles importan.

La respuesta a incidentes también cambia. Ante un endpoint comprometido, no basta con resetear una contraseña. Hay que revocar sesiones, retirar dispositivos, revisar passkeys recientes, rotar factores de recuperación, comprobar OAuth grants, re-enrolar confianza y analizar registros de inicio de sesión. Passwordless necesita playbooks passwordless.

Cierre tranquilo

Las passkeys no están rotas ni son mágicas. Son una mejora enorme sobre contraseñas porque eliminan secretos reutilizables de la entrada diaria. Reducen phishing, credential stuffing y daño por reutilización. No eliminan malware, recovery débil ni implementaciones WebAuthn pobres. La regla práctica es mantenerlas, proteger los dispositivos, usar llaves hardware para lo crítico y exigir a los servicios una implementación seria. La pregunta ante cada titular debe ser: ¿falló la criptografía de inicio de sesión o volvió a fallar el entorno que la rodea?