Passkeys contra el relé de phishing: por qué la vinculación al origen gana a los códigos de un solo uso
Los kits de phishing que se colocan entre el usuario y la página de inicio de sesión genuina se han convertido en una de las formas más fiables de derrotar la autenticación multifactor. La víctima escribe un código de un solo uso, el kit lo retransmite al sitio real en segundos y el atacante se queda con la sesión que regresa. Una passkey rompe ese relé como ningún método basado en códigos: simplemente no hay nada en la pantalla que copiar.
Cómo los kits AiTM devoran los códigos de un solo uso
Microsoft documentó la mecánica al detalle: siguió una campaña que golpeó a más de 10.000 organizaciones desde septiembre de 2021. El atacante ejecuta un proxy inverso que sirve una copia píxel a píxel de la página real de inicio de sesión bajo su propio dominio y mantiene dos sesiones TLS: una con la víctima y otra con el sitio genuino. Las contraseñas y las cookies de sesión fluyen por el medio, y el atacante inicia sesión como el usuario. Microsoft subrayó que esto no es una vulnerabilidad del MFA; el código es genuino, el inicio de sesión es genuino y el kit simplemente se queda con lo que el usuario entrega (Microsoft). La técnica no se ha desvanecido. En enero de 2026, investigadores de Microsoft describieron una campaña AiTM multifase contra organizaciones del sector energético que llegó mediante enlaces de SharePoint abusados y acabó en fraude económico (Microsoft). Un año de telemetría de Kaspersky publicado en agosto de 2026 contabilizó más de 390.000 páginas de phishing en plataformas legítimas de nube, muchas con bibliotecas proxy de código abierto y ventanas browser-in-the-browser que falsifican la barra de direcciones (Kaspersky). El kit moderno retransmite el código, la aprobación push y la cookie resultante en tiempo real. Todo salvo la URL es real.Vinculación al origen: el dominio es parte de la credencial
WebAuthn, el estándar detrás de las passkeys, funciona de otra manera. En el registro, el sitio y el navegador crean un par de claves pública y privada acotado a un ID de parte confiable (relying party ID), que en la práctica es el dominio del sitio. La clave privada nunca sale del dispositivo y el navegador solo ofrece una credencial cuando el origen de la página coincide con ese ID. La documentación de Mozilla lo resume sin rodeos: un atacante que construye un sitio falso de inicio de sesión no puede entrar como el usuario, porque la firma cambia según el origen del sitio web (Mozilla). La FIDO Alliance describe las passkeys como únicas por sitio o aplicación, y eso es justo lo que deja sin material al credential stuffing (FIDO Alliance). Cisco Talos mostró lo que esto significa para los kits proxy: una víctima que cae en un dominio falso que imita a su banco no puede completar la ceremonia WebAuthn, porque el navegador no ofrece una credencial ligada al dominio real en el falso. La autenticación falla antes de que se transmita cualquier secreto (Cisco Talos).Un kit proxy puede retransmitir todo lo que el usuario escribe. No puede retransmitir una credencial que el navegador nunca ofrece.Incluso donde la ceremonia ocurre, nada reutilizable cruza el cable. El servidor envía un challenge aleatorio muy grande, el autenticador lo firma con la clave privada y la firma demuestra la posesión sin revelar ningún secreto, como señala la especificación de Mozilla. Un proxy puede reenviar esa firma, pero el sitio genuino vería entonces una respuesta que reclama un origen que nunca sirvió, con una credencial cuyo ID de parte confiable comprueba precisamente para este caso. No hay código corriendo contra un temporizador de treinta segundos ni cookie acuñada en el lado del atacante.