Resumen

  • RFC 10027 estudia ataques en los que el usuario se autentica de verdad, pero autoriza una solicitud iniciada en el dispositivo del atacante. Falta demostrar que la decisión pertenece al contexto que la persona cree ver.
  • Un código QR válido puede identificar una operación pendiente sin probar quién la inició, dónde se mostró, qué esperaba el usuario ni qué cliente recibirá los tokens.
  • Daniel Fett firma la BCP con Pieter Kasselman y Filip Skokan. El documento recomienda elegir el protocolo según el riesgo y combinar proximidad, dispositivos confiables, ámbitos limitados, detección y recuperación.

Imaginemos una pantalla compartida en una oficina. Pide escanear un código para abrir archivos. El móvil lleva al proveedor de identidad auténtico, solicita la contraseña real y completa el segundo factor. La experiencia parece más segura que escribir credenciales en una pantalla ajena.

Ahora cambiemos solo al dueño de la solicitud inicial. Un atacante abre el flujo en su propio equipo, obtiene el código emitido por el servidor y lo envía a la víctima como parte de una supuesta incidencia. La víctima escanea, se autentica y pulsa aceptar. El proveedor ha comprobado quién es la persona. No necesariamente ha comprobado frente a qué pantalla está ni qué equipo originó la operación.

Ese desfase es el centro de RFC 10027, publicada por el IETF en agosto de 2026. Pieter Kasselman, Daniel Fett y Filip Skokan describen una familia de ataques contra flujos de autorización y transferencia de sesión entre dispositivos. El canal humano que transporta un QR, un código corto o el significado de una notificación carece a menudo de autenticación propia.

Cuando la MFA funciona y aun así se concede mal

Llamar al episodio «evasión de MFA» borra la causa. La autenticación puede haber funcionado exactamente como fue diseñada. Lo que no quedó vinculado fue el dispositivo consumidor, la iniciativa, el propósito mostrado y el alcance de la concesión.

En el Cross-Device Consent Phishing, el atacante logra que la víctima autorice acceso. En el Cross-Device Session Phishing, consigue un artefacto que traslada una sesión ya autenticada. No hace falta capturar la contraseña. La recompensa puede consistir en tokens de acceso y actualización o en una sesión utilizable. Por eso un cambio de contraseña aislado no demuestra que la exposición terminó.

El código tampoco es inútil. Puede probar que el servidor emitió una referencia válida, única y no caducada. Pero no prueba quién puso el código ante la persona, si esta inició la tarea, si ambos dispositivos están próximos, si el cliente es el esperado, si el alcance es necesario o si el uso posterior coincide con la intención. La evidencia técnica es correcta dentro de un ámbito más estrecho de lo que sugiere la interfaz.

La disciplina que aporta Daniel Fett

Fett se presenta en su sitio profesional como consultor especializado en seguridad de identidad y protocolos web, con trabajo en OAuth y OpenID Connect dentro de OpenID Foundation e IETF. El registro del IETF recoge RFC sobre identificación del emisor, prueba de posesión, seguridad OAuth y divulgación selectiva. RFC 10027 es obra conjunta de tres autores; esa trayectoria no le atribuye control sobre productos ni despliegues.

Su relevancia reside en separar propiedades. El análisis formal puede mostrar que no existe un ataque dentro de un modelo que define capas, capacidades del adversario y objetivos. No puede certificar los detalles que el modelo abstrae ni los errores de una implementación. Del mismo modo, la palabra «autenticado» no debería aparecer sin sujeto y objeto.

La identidad del usuario, el dispositivo iniciador, el contexto, la intención, la concesión, el destino del token y el acceso al recurso son hechos distintos. Un servidor auténtico puede presentar una solicitud iniciada por el adversario. Un token ligado a una clave puede quedar ligado a la clave del propio dispositivo malicioso. Una persona puede querer activar la pantalla que tiene delante y autorizar, sin saberlo, otra máquina remota.

Controles que elevan el coste, no crean certeza

RFC 10027 evita la lista triunfalista de soluciones. Cada defensa incluye límites.

Los códigos de vida corta y de un solo uso dificultan la repetición, pero un atacante interactivo puede generarlos cuando la víctima ya está preparada. Las cuotas frenan volumen, no precisión. La formación ayuda a reconocer mensajes extraños; un flujo legítimo reutilizado con una historia convincente puede superar incluso a un usuario atento.

La proximidad añade una relación observable. BLE, NFC, UWB, red compartida o señales de ubicación pueden impedir que un código viaje libremente. Sin embargo, VPN, localización simulada, NAT, datos móviles y autorizadores legítimamente remotos impiden equiparar proximidad con consentimiento. El servidor valida señales; no mide por sí solo la distancia física ni la intención.

Permitir iniciación solo desde dispositivos administrados o redes confiables reduce la superficie. Esa confianza exige alta, atestación, parches y revocación. Un dispositivo confiable comprometido sigue siendo peligroso. Reducir ámbitos y duración limita el impacto después de una concesión errónea. Los tokens restringidos al emisor dificultan su reventa o traslado, pero el equipo atacante que posee la clave puede utilizarlos donde se emitieron.

El documento prefiere FIDO para autenticación entre dispositivos cuando es posible unir origen y proximidad. CIBA ofrece otra vía cuando el servidor ya dispone de un canal hacia el usuario, aunque necesita defensa contra solicitudes no esperadas. El Device Authorization Grant de OAuth funciona con el mínimo común denominador de hardware; RFC 10027 aconseja reservarlo para cuando las alternativas más fuertes no sean viables y evitarlo en recursos sensibles o críticos sin mitigaciones adicionales.

Un recibo que una aprobación no contiene

La primacía del código en funcionamiento de Heng Lu sugiere una prueba sencilla: no basta la declaración «aprobado»; hay que observar qué capacidad llegó a qué sistema y qué ocurrió después.

Un recibo responsable enlaza identidad y estado del cliente iniciador, dispositivo de autorización, método, contexto mostrado en ambas pantallas, alcance, señales de proximidad, decisión, restricciones del token, primer uso, anomalías, revocación y recuperación. Debe conservar solo lo necesario y con controles de privacidad. Sin esa unión, el icono verde confirma una etapa y oculta el resultado.

También distribuye responsabilidades. Producto decide si la comodidad justifica el flujo. Identidad elige protocolo y permisos. Equipos de dispositivo y red gestionan confianza y proximidad. Fraude analiza patrones de inicio y aprobación. Los servidores de recursos hacen cumplir restricciones. Soporte e incidentes eliminan concesiones y verifican la recuperación. El usuario no puede cargar con la autenticación exclusiva de un canal que el sistema dejó sin autenticar.

La conclusión no es que un QR sea inseguro por naturaleza. Es que un código transporta una referencia, no la autoridad completa de la historia que lo acompaña.

Fuentes