SHIELD

Identidad y cuentas

MFA: por qué su app Google Authenticator le traiciona

No todas las soluciones MFA son iguales. Anatomía de los ataques que superan el TOTP, y la ruta de migración hacia FIDO2.

Publicado el 16 min de lectura Exposed

Última revisión:

Llave de seguridad USB sobre fondo oscuro

Un cliente me muestra orgulloso su teléfono. Google Authenticator, una veintena de cuentas dentro, copia de seguridad sincronizada. «Estoy blindado.» Tres semanas antes, su cuenta de Google había servido de puerta de entrada: un correo falso de compartición de documento, una página de inicio de sesión idéntica a la de Google, un código de seis cifras copiado sin pensar. El atacante no rompió nada. El cliente le tendió el código, en tiempo real, como quien entrega las llaves al aparcacoches. Y su «blindaje» estaba sincronizado en la cuenta que acababa de caer.

Angle de lecture

La trampa habitual

«He activado el 2FA, estoy protegido.» Es la frase que más oigo en auditoría, y la más peligrosa del vocabulario de la seguridad personal. No porque sea falsa en sentido estricto —el MFAAutenticación de múltiples factores: combinar dos pruebas de identidad independientes para iniciar sesión. reduce realmente el riesgo respecto a una simple contraseña. Sino porque clasifica en una única casilla «protegido / no protegido» dispositivos que no tienen nada que ver entre sí en términos de robustez.

El MFA no es una categoría única, es un espectro. En un extremo, el código por SMS, que cae al primer SIM swappingAtaque en el que un fraude convence a tu operador de transferir tu número a una SIM propia. que llegue. En el medio, el TOTPCódigo de 6 dígitos generado cada 30 segundos por una app (Google Authenticator, Authy, etc.). —esos códigos de seis cifras que cambian cada treinta segundos, el famoso Google Authenticator. En el otro extremo, el FIDO2Estándar de autenticación fuerte mediante clave criptográfica de hardware, resistente al phishing., una llave física o una passkeyImplementación de FIDO2 para el gran público: clave de autenticación almacenada y sincronizada por Apple/Google/Microsoft. que se niega físicamente a autenticarse en el dominio equivocado. Entre el SMS y el FIDO2 hay dos órdenes de magnitud de diferencia en la resistencia al phishingAtaque de ingeniería social que empuja a la víctima a dar sus credenciales o ejecutar código.. Meter todo eso en el mismo saco «2FA» es decir «tengo una cerradura» sin precisar si es un pestillo de baño o un bombín certificado de alta seguridad.

La consecuencia práctica es doble, y las dos caras son malas. Por un lado, gente que se cree protegida y no invierte en la verdadera protección, porque piensan que ya han marcado la casilla. Por otro, la ilusión que se derrumba en el peor momento —durante un ataque dirigido, en un viaje, sobre la cuenta que pilota toda su vida digital. El TOTP no es inútil. Pero venderlo como un fin de partida es la raíz del problema.

El modelo de amenaza real: lo que supera el TOTP

El malentendido de fondo es creer que el TOTP protege contra el phishing. No protege. Protege contra una cosa precisa —el robo de contraseña sin interacción en tiempo real con la víctima— y nada más. Frente a un atacante que le habla en el momento en que se conecta, el código de seis cifras es un factor más que copiar, no un muro.

He aquí la mecánica concreta, la que veo en los expedientes. El atacante no construye una página falsa estática que recoge su contraseña para reproducirla más tarde. Monta un reverse-proxyAtaque en el que un actor se interpone en una comunicación entre dos partes que creen estar en contacto directo. entre usted y el servicio real —es un ataque llamado adversary-in-the-middle (AiTM). Usted llega a una página que es, byte a byte, la página de inicio de sesión real: no es una copia, es la página real retransmitida en tiempo real. Teclea su usuario, el proxy lo transmite a Microsoft o Google. El servicio real pide el código TOTP. Usted lo teclea. El proxy también lo transmite. El servicio valida y devuelve una cookie de sesión autenticada —y es esa cookie la que el atacante captura. Tiene ahora su sesión activa. El código de seis cifras ya había sido consumido; le da igual, tiene algo mejor: está conectado como usted, sin tener que volver a pasar por el MFA.

Este instrumental no está reservado a Estados-nación. Frameworks de código abierto como EvilginxAtaque de ingeniería social que empuja a la víctima a dar sus credenciales o ejecutar código. hacen exactamente eso, llave en mano, con «phishlets» preconfigurados para Office 365, Google Workspace, Okta, los principales proveedores. El kit de phishing AiTM se alquila por suscripción en los foros criminales —«phishing-as-a-service», con hospedaje, certificado TLSProtocolo de cifrado de transporte, base de HTTPS y de la seguridad web moderna. válido para el dominio señuelo y panel de control para cosechar las sesiones robadas. El listón técnico para eludir su TOTP ha caído al nivel de un script-kiddie motivado. Microsoft ha documentado campañas AiTM que afectaron a decenas de miles de organizaciones. No es ni teórico, ni raro.

El detalle que duele en este escenario es que todos los reflejos que le enseñaron para detectar el phishing fallan aquí. ¿El candado TLS en la barra de direcciones? Presente —el atacante tiene un certificado real para su dominio señuelo. ¿La página que «parece real»? Es real, retransmitida píxel a píxel. ¿El código TOTP que teclea «porque sí es el sitio bueno»? Transita. E incluso la notificación push de validación, supuestamente «más segura» que el TOTP, no resuelve nada: el atacante desencadena la conexión legítima en el momento en que usted valida, así que aprueba su sesión creyendo aprobar la suya. Es la «fatiga MFA» en su versión quirúrgica. Todo lo que reposa sobre un humano que copia o aprueba un secreto en el momento adecuado es vulnerable, porque el humano no puede distinguir el buen momento del malo cuando el proxy es perfecto.

Hay que matar también una idea preconcebida tenaz: «el TOTP es matemáticamente sólido, así que la app TOTP es sólida». Las dos proposiciones no tienen nada que ver. Sí, el algoritmo de la RFC 6238Código de 6 dígitos generado cada 30 segundos por una app (Google Authenticator, Authy, etc.). es de hierro —un HMAC sobre un contador temporal, nada que objetar. Pero la robustez de un factor de autenticación no se mide por la fuerza de su algoritmo; se mide por lo que hace falta para eludirlo en condiciones reales. Y en condiciones reales, no se rompe el HMAC: se intercepta el código en tránsito, o se roban las semillas en reposo. El algoritmo perfecto no protege nada si el secreto que manipula se filtra por los lados.

Y eso es solo el vector en línea. El TOTP tiene un segundo talón de Aquiles, más banal: la copia de seguridad en la nube. Es la trampa de mi cliente en la apertura. Cuando sincroniza Google Authenticator con su cuenta de Google, o Authy con su cuenta de Authy, sus semillas TOTP —los secretos que generan los códigos— abandonan su teléfono para vivir en una nube. A partir de ahí, su «segundo factor» ya no es independiente del primero: comprometer la cuenta en la nube compromete el conjunto de sus códigos de un solo movimiento. Ha transformado un factor de posesión en una extensión de su cuenta de correo. El día en que esa cuenta caiga —phishing, contraseña reutilizada, fuga— el atacante recupera la bóveda entera.

El buen enfoque: jerarquizar, luego pasar lo crítico a FIDO2

La salida no es «suprima el TOTP». Es «deje de tratar todas sus cuentas igual, y ponga la verdadera protección donde importa». Establezca primero la jerarquía de robustez, de lo peor a lo mejor: SMS, luego TOTP en la nube, luego TOTP local, luego FIDO2 físico. Cada peldaño sube un escalón la resistencia al phishing. El SMS cae con el SIM swapping. El TOTP en la nube cae con la cuenta en la nube. El TOTP local resiste al robo a distancia de las semillas pero sigue siendo «phishable» en tiempo real vía AiTM. El FIDO2, en cambio, rompe el ataque AiTM por construcción.

Por qué el FIDO2 es diferente y no solo «mejor»: la criptografía de WebAuthnAPI del navegador que permite la autenticación FIDO2 en sitios web. liga la autenticación al dominio. La llave firma una respuesta que incluye el origen exacto del sitio solicitante. Si está en login-microsoft.atacante.com en lugar de login.microsoftonline.com, la firma no coincide, y la llave se niega —sin que usted tenga que detectar nada, sin juicio humano, sin «¿es rara esta URL?». El secreto nunca abandona el elemento físico: no hay código que copiar, así que nada que interceptar en el proxy. Es lo que el INCIBE y el NISTInstituto americano que publica los estándares de referencia en ciberseguridad (CSF, SP 800-*). llaman un MFA «resistente al phishing», por oposición a todo el resto. La distinción no es de marketing, es estructural.

El cambio pragmático cabe en una regla: todo lo que pueda restablecer el resto pasa primero. Su correo principal es la raíz —es por él por donde transitan todos los restablecimientos de contraseña. Póngalo bajo FIDO2 antes que nada. Luego las cuentas financieras, luego el gestor de contraseñas, luego las consolas de administración si tiene. Para el resto —los centenares de cuentas secundarias donde FIDO2 no se ofrece o no se justifica— conserve TOTP, pero local, en una app que no sincronice sus semillas en una nube ligada a su identidad. Aegis en Android, Raivo o Ente Auth en iOS: semillas cifradas en el dispositivo, exportación manual cifrada para la copia de seguridad, sin copia automática en la cuenta que el TOTP se supone que protege. Y jamás, jamás el TOTP en el mismo gestor de contraseñas en la nube que las contraseñas: si no, un solo compromiso da el factor 1 y el factor 2.

En concreto, el orden de las operaciones cuenta tanto como el objetivo, porque la migración es el momento en que uno se bloquea a sí mismo por torpeza. La secuencia que hago aplicar: primero, registro las dos llaves FIDO2 en la cuenta objetivo mientras el método antiguo sigue activo —nunca se añade un factor fuerte suprimiendo el antiguo en el mismo gesto. Después pruebo una desconexión / reconexión completa con cada una de las dos llaves, por separado, para verificar que ninguna ha quedado registrada a medias. Luego recupero y almaceno sin conexión los códigos de recuperación que el servicio genera —en papel, no en el gestor que depende a su vez de esa cuenta. Y solo entonces retiro los métodos débiles: SMS, OTP por correo, y en su caso el TOTP que se ha vuelto redundante. Saltarse una de estas etapas es o bien quedarse fuera, o bien dejar una puerta débil abierta «provisionalmente» —y lo provisional dura.

El apartado del TOTP local merece la misma disciplina, porque su punto débil no es el ataque sino la pérdida. Una app local que no sincroniza nada es exactamente lo que se quiere del lado de la seguridad —y exactamente lo que le condena el día en que el teléfono acaba en un inodoro si no tiene copia de seguridad. La defensa cabe en dos gestos: una exportación cifrada de las semillas (Aegis lo hace en AES, protegido por una frase de contraseña fuerte) almacenada en un soporte sin conexión, y la conservación de los códigos de recuperación de cada servicio en el momento del registro. No necesita una nube para sobrevivir a la pérdida de un dispositivo; necesita una exportación cifrada que usted controla y una frase de contraseña que solo usted conoce.

Queda la cuestión de las passkeys, porque se las van a vender como la respuesta universal. Una passkeyImplementación de FIDO2 para el gran público: clave de autenticación almacenada y sincronizada por Apple/Google/Microsoft. es FIDO2 bajo un nombre de consumo: misma resistencia al phishing por ligadura al dominio, misma criptografía WebAuthnAPI del navegador que permite la autenticación FIDO2 en sitios web.. El matiz está en el almacenamiento. Una passkey sincronizada en iCloud o en su cuenta de Google hereda la seguridad de esa cuenta —lo cual está muy bien para sus cuentas ordinarias, y es discutible para el puñado de cuentas cuyo compromiso es precisamente el escenario que quiere excluir. Para esas cuentas, prefiera una passkey no sincronizada almacenada en la propia llave física, o conserve dos llaves FIDO2 físicas. Para todo lo demás, la passkey sincronizada es un excelente compromiso entre robustez y practicidad, y muy superior al TOTP.

Último punto que no es opcional: dos llaves FIDO2 como mínimo. Una que usted lleva encima, una de respaldo en un lugar seguro, las dos registradas en cada cuenta crítica. El modo de fallo clásico del FIDO2 no es el ataque, es la pérdida de la llave única que le deja fuera. Una sola llave es un punto único de fallo. Dos llaves son resiliencia.

Lo que esto implica en concreto

Para usted, como persona

  1. Compre dos llaves FIDO2 y pase primero su correo principal — Dos YubiKey 5 o dos llaves Solo/Token2 (~50-110 € el par según el modelo), registradas las dos en su cuenta de Google/Microsoft/Proton. Es la cuenta raíz: mientras esté bajo TOTP «phishable», todo lo demás es recuperable por un atacante que supere su MFA. Una llave encima, una guardada en casa.
  2. Corte la copia de seguridad en la nube de su app TOTP y migre a local — Si está en Google Authenticator sincronizado o Authy, sus semillas están en una nube ligada a su identidad. Pase a Aegis (Android) o Raivo / Ente Auth (iOS), desactive toda sincronización automática, haga una copia de seguridad manual cifrada almacenada fuera de esa nube. Coste: cero, una hora de su tiempo.
  3. Nunca ponga sus códigos TOTP en el mismo gestor que sus contraseñas — Si su gestor de contraseñas en la nube aloja también sus TOTP, una sola fuga da los dos factores. Manténgalos separados, en dos soportes que no caigan juntos.

Para usted, CISO / Dirección de TI / dirección

1. Plantee el criterio AiTM como pregunta binaria. Para cada población de usuarios y cada aplicación sensible, pregunte: «¿este MFA resiste un ataque adversary-in-the-middle en tiempo real?» Si la respuesta no es «sí, porque FIDO2 / passkey ligada al dominio», es no —el TOTP y los push aprobables caen frente a un kit Evilginx alquilado por suscripción. Consecuencia directa: toda cuenta con privilegios (admin IAMGestión centralizada de identidades y accesos a los recursos., accesos financieros, cuentas de break-glass) aún bajo TOTP es una brecha que documentar en su registro de riesgos, fechada, con un plan de remediación.

2. Despliegue FIDO2 por círculos concéntricos, no en big-bang. Empiece por los administradores y las cuentas de alto privilegio, luego las funciones expuestas (dirección, finanzas, RR. HH., jurídico), luego el resto. Aprovisione dos autenticadores por usuario crítico y desactive los métodos débiles (SMS, OTP por correo) en esas poblaciones una vez hecho el cambio. Consecuencia directa: reduce la superficie AiTM allí donde el impacto es máximo sin bloquear a toda la organización en un solo proyecto, y elimina el rodeo «vuelvo al SMS» que anula todo el beneficio.

3. Trate la recuperación de cuenta como el eslabón débil. Un MFA resistente al phishing no sirve de nada si el proceso de restablecimiento, en cambio, acepta una llamada al servicio de soporte con tres datos públicos. Documente y endurezca los recorridos de recuperación (verificación de identidad fuerte, segundo canal, alerta ante restablecimiento de MFA). Consecuencia directa: cierra la puerta trasera por la que un atacante elude FIDO2 sin atacarlo jamás —es hoy el vector predilecto contra las organizaciones que han hecho bien todo lo demás.

Para usted, como dirección general

Su CISO le ha dicho que el MFA estaba activado en todas partes. Tiene razón, probablemente. Pero «activado» no responde a la única pregunta que importa, y es ahí donde el malentendido sale caro.

No todos los MFA son iguales. Ni mucho menos. En la mayoría de las organizaciones, lo que está desplegado es código por SMS o una aplicación que muestra seis cifras. No porque proteja mejor. Porque es más barato, más rápido de generalizar, y porque marca la casilla de auditoría. La seguridad real no entró en el arbitraje. El coste, sí.

Esto es lo que esos dos métodos no aguantan. El SMS cae cuando un atacante convence a su operador de transferir su número a su tarjeta SIM. Una hora de manipulación, y sus códigos llegan a su poder. La aplicación que muestra seis cifras cae cuando el atacante le habla en el momento exacto en que se conecta: retransmite su código en tiempo real al servicio real, sin que usted vea nada. Ninguno de estos dos métodos resiste a alguien que le elige de verdad como objetivo.

La llave física, en cambio, se niega a autenticarse en el sitio equivocado. No por juicio humano. Por construcción. Es la única diferencia que aguanta frente a un adversario determinado.

La pregunta que plantear, en su próximo punto de seguridad: «nuestro MFA, ¿es SMS, una aplicación, o una llave física?» Y si la respuesta mezcla los tres, pregunte cuáles protegen sus cuentas críticas y las de su dirección financiera.

La prueba no es saber si el MFA está activado. Todo el mundo responde que sí a esa pregunta, y todo el mundo se equivoca al conformarse con eso. La prueba es saber si resiste a alguien que quiere de verdad entrar.

Errores que se ven constantemente

  • Sincronizar las semillas TOTP en la nube de la cuenta que protegen. Google Authenticator respaldado en Drive, Authy bloqueado por SMS: el segundo factor ya no es independiente del primero. Un compromiso, todo cae.
  • Creer que el TOTP detiene el phishing. Detiene el robo de contraseña reproducido más tarde. No hace nada contra un reverse-proxy AiTM que retransmite su código en tiempo real. La distinción es toda la diferencia.
  • Mezclar contraseñas y TOTP en el mismo gestor en la nube. Cómodo, y ese es el problema: factor 1 y factor 2 en la misma cesta, una sola fuga los da los dos.
  • Una sola llave FIDO2, sin respaldo. El día en que la pierda, se queda fuera —o peor, reabre de urgencia un método débil «mientras tanto» y no lo vuelve a cerrar nunca.
  • Activar FIDO2 en las cuentas críticas pero dejar el SMS como respaldo. Un atacante no ataca su llave: toma la opción más débil aún disponible. Mientras exista el respaldo débil, el FIDO2 no sirve de nada.
  • Olvidar el recorrido de recuperación. Ha endurecido la conexión, no el restablecimiento. El servicio de soporte que recoloca un MFA con tres datos públicos anula todo el trabajo.

Checklist accionable

  • N1 Listar las cuentas críticas (correo principal, banco, gestor de contraseñas, consolas de admin)
  • N1 Desactivar la copia de seguridad/sincronización en la nube de la app TOTP existente
  • N1 Migrar el TOTP a una app local sin sincronización en la nube (Aegis, Raivo, Ente Auth)
  • N2 Comprar dos llaves FIDO2 y registrar las dos en el correo principal
  • N2 Separar físicamente las contraseñas y las semillas TOTP (soportes distintos)
  • N2 Pasar banco y gestor de contraseñas a FIDO2 cuando esté disponible
  • N3 Desactivar el SMS y el OTP por correo como respaldo en las cuentas pasadas a FIDO2
  • N3 Aprovisionar una llave FIDO2 de respaldo almacenada fuera del domicilio principal
  • N3 Auditar y endurecer los recorridos de recuperación de cuenta (verificación de identidad fuerte)

Para profundizar

La distinción entre MFA «phishable» y MFA resistente al phishing no es una opinión: está escrita negro sobre blanco por el NIST (SP 800-63B) y detallada por el INCIBE en sus guías de implementación del MFA resistente al phishing —las dos referencias que leer si debe argumentar una migración internamente. Para comprender lo que FIDO2 garantiza criptográficamente, consulte las especificaciones de FIDO Alliance; para el funcionamiento exacto del TOTP y sus límites, la RFC 6238 es corta y legible. Y si aún duda de que el ataque AiTM esté al alcance de un atacante ordinario, la documentación pública de Evilginx basta para hacerse una idea del nivel de esfuerzo real —es decir, bajo.

Fuentes y lecturas complementarias