Resumen
La MFA convencional con contraseña y OTP o push reduce el riesgo de una contraseña robada, pero los códigos introducidos y las aprobaciones no están necesariamente vinculados al servicio legítimo. Un atacante puede retransmitir OTP mediante phishing adversary-in-the-middle, provocar fatiga de notificaciones o robar una sesión bearer después de autenticar.
La autenticación vinculada al dispositivo cambia la propia credencial. Una passkey vinculada conserva su clave privada en un autenticador concreto, como una llave de seguridad, TPM o Secure Enclave, sin exportación ni sincronización. WebAuthn vincula además cada assertion a la parte de confianza y a un desafío nuevo, por lo que la ceremonia resiste phishing y replay.
Esto evita el phishing de credenciales y la copia de la clave privada, pero no vincula automáticamente cada sesión de aplicación al dispositivo. Muchas aplicaciones siguen usando cookies bearer reutilizables. Se necesitan duraciones cortas, reautenticación basada en riesgo, proof of possession o credenciales de sesión vinculadas.
La vinculación tampoco equivale a confiar en un dispositivo administrado. Una credencial no exportable puede residir en un dispositivo personal. La atestación puede aportar datos de procedencia en el registro; el parcheado, cifrado y estado actual del agente provienen de señales de gestión y postura independientes.
Cinco controles responden preguntas distintas
- Presencia del usuario. ¿Una persona realizó un gesto de autorización, como tocar una llave de seguridad?
- Verificación del usuario. ¿El autenticador verificó localmente al usuario mediante biometría, PIN o equivalente?
- Vinculación de credenciales. ¿La clave privada no es exportable y está limitada a un autenticador concreto?
- Confianza del dispositivo administrado. ¿La organización reconoce, administra y confía en el endpoint que usa la credencial?
- Vinculación de sesión. ¿El cliente debe seguir demostrando posesión de una clave criptográfica después de autenticar o basta una cookie bearer?
Comparación de controles
| Control | Qué demuestra | Resistente al phishing | Detiene la reutilización de una sesión bearer robada |
|---|---|---|---|
| Contraseña más OTP | Conocimiento de una contraseña y acceso a una fuente OTP | No | No |
| Contraseña más push | Conocimiento de una contraseña y capacidad de aprobación en un autenticador registrado | No necesariamente | No |
| Passkey sincronizada | Posesión de una passkey disponible mediante el proveedor y autorización local | Sí | No |
| Passkey vinculada al dispositivo | Posesión de una clave no exportable en un autenticador concreto | Sí | No |
| Acceso condicional de dispositivo administrado | El endpoint cumple las políticas de registro y postura | Depende del método de autenticación | No |
| Sesión vinculada al dispositivo | Posesión continua de una clave criptográfica de sesión | No es un método de autenticación | Reduce el replay si se implementa correctamente |
Ataques cubiertos y límites
- Phishing y relay de credenciales. WebAuthn vincula la credencial al nombre del verificador, por lo que un sitio falso no obtiene una assertion válida para la parte de confianza legítima.
- Fatiga de notificaciones. Las passkeys eliminan el patrón de aprobación push reutilizable que un atacante puede provocar repetidamente.
- Replay de autenticación. Un desafío nuevo del servidor impide reutilizar una assertion de WebAuthn grabada.
- Robo de tokens de sesión. Es un riesgo independiente posterior a la autenticación. Una credencial vinculada no convierte una cookie bearer normal en una sesión vinculada.
- Acceso desde equipos no administrados. Debe controlarse mediante registro del dispositivo y acceso condicional; la vinculación de credenciales no demuestra que TI administre el endpoint.
Qué evaluar
- Nivel de garantía. Define qué roles necesitan passkeys vinculadas y dónde basta una passkey sincronizada bajo control empresarial.
- Política de atestación. Documenta si se solicita, qué raíces y modelos se aceptan, cómo se protege la privacidad y qué ocurre cuando falta.
- Detección y postura del dispositivo. Define cómo se identifican los endpoints aprobados, qué señales se usan, cuánto tiempo siguen vigentes y la respuesta ante datos ausentes u obsoletos.
- Protección de sesión. Evalúa duración de cookies, almacenamiento de tokens, reautenticación, anomalías, revocación y proof of possession.
- Recuperación y excepciones. Mantén la recuperación resistente al phishing y diseña rutas controladas para BYOD, contratistas, dispositivos compartidos, acceso de emergencia y plataformas no compatibles.
Cómo usar este recurso
Alinea seguridad, TI y compras sobre la protección que ofrecen la MFA convencional, las credenciales vinculadas, la postura del dispositivo y la vinculación de sesión. Convierte las diferencias en criterios de aceptación medibles para una prueba de concepto.