Doble factor de autenticación (2FA) y autenticación multifactor (MFA)

El doble factor de autenticación (2FA) exige presentar dos formas distintas de identificación antes de entrar en un sistema, en vez de depender solo de la contraseña. Es el caso más común de la autenticación multifactor (MFA), que es el mismo mecanismo cuando se piden dos factores o más.

Los factores se agrupan en tres categorías: algo que sabes (una contraseña), algo que tienes (un móvil, un token, una tarjeta) y algo que eres (biometría como la huella o el reconocimiento facial). La exigencia es que sean de categorías distintas: dos contraseñas no son doble factor.

La capa extra sirve para que una contraseña robada no baste por sí sola. Las formas más habituales son los códigos temporales de una aplicación de autenticación, los dispositivos físicos y la biometría. Cuál de ellas se elige no es indiferente, y la sección siguiente explica cuál aguanta qué ataque.

La premisa es que a un atacante le resulta improbable obtener evidencia de dos clases distintas a la vez. Robar una contraseña es fácil y robar una contraseña más la posesión física de un dispositivo registrado es mucho más difícil, así que exigir las dos sube el coste de tomar una cuenta muchísimo más de lo que lo sube cualquier política de contraseñas.

Las categorías son lo que hace que funcione. Algo que sabes: una contraseña, un PIN, un código de recuperación. Algo que tienes: una llave de seguridad física, un teléfono que guarda una clave privada ligada al dispositivo, una tarjeta inteligente. Algo que eres: una huella o una cara, que en la práctica desbloquea una clave en el dispositivo en vez de viajar a ninguna parte. Dos elementos de la misma categoría no multiplican la dificultad, y por eso una contraseña más una pregunta de seguridad es autenticación de un solo factor con pasos de más.

Los mecanismos se diferencian enormemente en lo que resisten, y ahí está casi toda la confusión. Un código por SMS, un código por correo y un código temporal de una aplicación de autenticación son todos secretos compartidos en tránsito: el usuario los lee y los teclea en algún sitio, así que cualquier cosa capaz de convencer al usuario de teclearlos en otro sitio se los lleva. Una aprobación por notificación es una decisión que el usuario toma sin más contexto que «aprobar o denegar». Una credencial WebAuthn es distinta en su naturaleza: el navegador firma un desafío con una clave privada que no sale del dispositivo, e incluye el origen del sitio que pregunta. Un sitio réplica no puede obtener una firma válida, porque la firma está atada al origen real. Esa única propiedad es la que la hace resistente y no simplemente incómoda.

El ataque que decide la mayoría de nuestros proyectos es el adversario en medio. Ponemos un proxy inverso delante de la página de acceso real. La víctima llega a nuestra página, ve el sitio auténtico porque se lo estamos retransmitiendo, mete su contraseña y completa con éxito el segundo factor que use, contra el sitio real. Entonces el sitio real emite una sesión, y nos la quedamos. No se rompió nada, no se saltó nada en el sentido criptográfico, y el segundo factor funcionó exactamente como estaba diseñado. Simplemente nos llevamos lo que produjo. Los códigos y las aprobaciones por notificación caen ante esto sin necesidad de modificarlo, y también cualquier factor que no esté atado al origen.

El segundo es la fatiga. Donde está habilitada la aprobación por notificación, un atacante que ya tiene la contraseña manda peticiones hasta que el usuario aprueba una, de noche, para que aquello pare. La coincidencia de número ayuda y no lo resuelve, porque un usuario al que le llegan avisos una y otra vez acabará leyendo el número y tecleándolo.

El tercero es la excepción, y es el que más encontramos. Un tenant exige MFA y arrastra una lista de cuentas excluidas por un motivo que tuvo sentido alguna vez: una cuenta de servicio, un administrador de emergencia, un dispositivo de sala de reuniones, un proveedor. En esas exclusiones es donde nos autenticamos. Junto a ellas, los protocolos de autenticación heredada anteriores a las políticas modernas aceptan una contraseña y nada más, y un solo endpoint heredado habilitado convierte en decorativa la exigencia de todo el tenant.

El cuarto es el registro y la recuperación. Si un usuario puede dar de alta un factor nuevo solo con su contraseña, un atacante con la contraseña da de alta el suyo. Si el servicio de soporte puede restablecer un factor tras verificar datos que están en un perfil público, el factor más fuerte del parque es una llamada de teléfono. En proyectos de ingeniería social, la vía del soporte funciona con más constancia que la técnica.

La pregunta nunca es «¿tenemos MFA?». Es «¿cuál de estos ataques detiene de verdad el factor que hemos desplegado?».

La columna que importa es la del proxy de phishing, porque ese es el ataque que se está usando ahora mismo contra organizaciones que ya tienen MFA desplegado. Todo lo que hay por encima de la fila del certificado comparte una propiedad: un valor o una decisión que el usuario entrega, lo que significa que se puede entregar al sitio equivocado. Todo lo que hay por debajo está atado al origen por el protocolo, así que una réplica no se lleva nada aprovechable.

Tratar todo el MFA como equivalente en un documento de política. «Se exige MFA» sin nombrar los factores aceptables permite el más débil de la lista.

Dejar habilitada la autenticación heredada. Un solo protocolo incapaz de llevar un segundo factor convierte la política en un consejo. Desactívala de forma central y audita las excepciones todos los meses.

Excluir las cuentas de servicio y olvidarse de ellas. Son cuentas, suelen tener más permisos que las personas, y son exactamente lo que buscamos.

Permitir el alta por autoservicio solo con la contraseña. El registro tiene que ser al menos tan fuerte como lo que se registra; si no, la contraseña sigue siendo el único control real.

Suponer que el MFA protege la sesión. Protege el momento del acceso. Un token de sesión robado no lleva ningún factor consigo, y por eso el secuestro de sesión posterior a un acceso correcto no se ve afectado por nada de esto.

Pasa primero a factores ligados al origen a los administradores y a cualquiera con acceso a dinero o a datos. Migrar el parque entero lleva tiempo; las cuentas que decidirían el proyecto pueden moverse este trimestre.

Cierra las alternativas. Desactiva la autenticación heredada, enumera todas las exclusiones con un responsable y una fecha de caducidad, y trata las cuentas de emergencia como un control diseñado, con factores físicos y vigilancia, en vez de como un hueco. Usa políticas de acceso condicional para que el estado del dispositivo y la ubicación entren en la decisión, y para que subir a un factor más fuerte sea obligatorio en las operaciones sensibles y no solo al iniciar sesión.

Arregla el registro y la recuperación con la misma seriedad que el factor principal. Alta desde un dispositivo de confianza o con comprobación presencial, verificación en soporte que no se pueda satisfacer con información pública, y aviso al usuario cada vez que se añada un factor.

Para detectar, las señales son concretas y suelen estar disponibles: autenticación correcta desde una dirección que es de un proveedor de alojamiento conocido, una secuencia de ubicaciones imposible, varios avisos denegados seguidos de una aprobación, y un factor nuevo registrado poco después de un restablecimiento de contraseña. Este último patrón es el indicador único más claro de toma de cuenta en casi todos los registros de identidad.

En un proyecto de phishing o de identidad informamos por ruta y no por tenant: qué cuentas, qué factor, qué protocolo y qué obtuvimos. Cuando hemos retransmitido un acceso por un proxy lo decimos con claridad, porque el cliente tiene que entender que su factor funcionó correctamente y aun así no bastó, que es una conversación distinta de la de una mala configuración.

La evidencia es la sesión que obtuvimos y a qué llegamos con ella, junto con las marcas de tiempo para que el cliente encuentre las entradas correspondientes en sus propios registros. No dejamos credenciales ni códigos en el cuerpo del informe.

La severidad la decide a qué llegó la cuenta y si la misma ruta funciona para una cuenta privilegiada. Retransmitir la sesión de un usuario corriente es un hallazgo serio; que la misma técnica funcione contra un administrador del directorio es el titular del informe.

Esto es exactamente lo que mide un ejercicio que termina en la sesión y no en el clic: no si la gente pincha, que eso ya lo sabe todo el mundo, sino con qué se queda el atacante después.

¿Merece la pena todavía el MFA por SMS? Es muchísimo mejor que una contraseña sola y es la opción más débil que hay. Si es lo que puedes desplegar hoy, despliégalo, y planifica el paso a factores ligados al origen para las cuentas privilegiadas en vez de tratar la casilla marcada como el final del trabajo.

¿Se puede saltar el MFA? La palabra saltar despista. Un proxy de phishing no derrota al factor: retransmite la sesión que el factor produjo. Los códigos, las aprobaciones por notificación y los enlaces de un solo uso son todos vulnerables a esto. Las credenciales WebAuthn no lo son, porque la firma está atada al origen del sitio real.

¿Qué es una passkey? Una passkey es una credencial WebAuthn, normalmente guardada en un teléfono o en un llavero de la plataforma y desbloqueada con biometría o PIN. Está ligada al origen igual que una llave física, y elimina la contraseña por completo en vez de añadirle un paso.

¿Seguimos necesitando contraseñas robustas con MFA? Sí, hasta que la contraseña desaparezca del todo. La contraseña sigue siendo un factor entero, es lo que prueba un ataque de credential stuffing, y en casi todos los parques hay al menos una ruta donde todavía se acepta sola.