2FA en 2026

Tras el artículo comentando el uso de Passkeys frente a las contraseñas tradicionales, cerramos el círculo de como proteger nuestras cuentas con un elemento que, sin ser una alternativa como plantean las primeras, se ha convertido en un refuerzo casi imprescindible de las segundas: el doble factor de autenticación. 2FA

El doble factor de autenticación surge para resolver un problema concreto; que el hecho de vulnerar una contraseña no sea suficiente para entrar en una cuenta. La mayoría de servicios lo implementan mediante un SMS (un código de seis dígitos que llega al móvil en cuestión de segundos). Es algo cómodo, universal pero prácticamente inútil contra ataques elaborados. Pese a eso, sigue siendo el método dominante porque no supone dificultad al usuario ni inversión al servicio. El resultado es una falsa sensación de seguridad que los atacantes llevan años aprovechando.

2FA. Idea vs implementación

Autenticarse es demostrar que eres quien dices ser. Históricamente, eso se ha resuelto mediante contraseñas: algo que sabes. El problema es que ese único factor puede robarse, filtrarse o romperse. El doble factor (2FA) añade una segunda capa de verificación basada en un concepto diferente: algo que tienes (un dispositivo, una llave física) o algo que eres (biometría).

El flujo básico es siempre el mismo: introduces tu contraseña, el servicio verifica que es correcta y después solicita el segundo factor. Si el atacante tiene tu contraseña pero no el segundo factor, no puede completar el acceso.

La solidez del sistema depende por completo de cuán difícil sea comprometer ese segundo factor.

Por qué sobrevive el SMS

Activar el 2FA por SMS no requiere instalar nada, aprender nada ni comprar nada. El servicio envía un código, el usuario lo teclea o incluso se copia y pega de forma automática.

El SMS es, por diseño, un canal sin cifrado de extremo a extremo. Los mensajes circulan por redes de telecomunicaciones sujetas a interceptación mediante el protocolo SS7, que data de los años ochenta y tiene vulnerabilidades ampliamente documentadas. Pero el vector de ataque más frecuente no requiere explotar SS7: basta con llamar a tu operador.

La propia CISA (la agencia de ciberseguridad de Estados Unidos) ha publicado recomendaciones explícitas para que las organizaciones de infraestructura crítica abandonen el SMS como segundo factor de autenticación, citando explícitamente dichas vulnerabilidades.

SIM swapping para hackear al operador

El SIM swapping es técnicamente simple. El atacante convence al servicio de atención al cliente del operador (mediante ingeniería social o con datos personales obtenidos anteriormente) de que es el legítimo propietario de la linea móvil y quiere transferir el número a una nueva SIM (duplicado de SIMs). Una vez completada la transferencia, todos los SMS que deberían llegarte (incluidos los códigos de doble factor) van al dispositivo del atacante.

Las cifras documentadas son elocuentes. El FBI registró 982 denuncias de SIM swapping en 2024 con pérdidas declaradas de casi 26 millones de dólares (una media de más de 26.400 dólares por víctima). En el Reino Unido, la base de datos nacional de fraude Cifas reportó cerca de 3.000 casos ese mismo año, lo que supone un incremento del 1.055% respecto a 2023. Australia registró un aumento del 240% en personas que buscaron asistencia por este tipo de fraude en el mismo período de tiempo.

Estos números reflejan solo los casos denunciados. La cifra real es a todas luces mayor; dado que muchas víctimas reportan fraudes sufridos (transferencias bancarias no autorizadas, robo de criptomonedas, usurpación de identidad) sin haber identificado el SIM swapping como vector de ataque.

La vulnerabilidad no está en nuestro comportamiento; está en el proceso de verificación del operador, totalmente ajeno a nuestro control. En 2019, Jack Dorsey, entonces CEO de Twitter, sufrió un SIM swapping que comprometió temporalmente su propia cuenta. En el ecosistema cripto, los ataques selectivos a wallets de alto valor han generado pérdidas individuales de millones de dólares documentadas en múltiples investigaciones judiciales.

La jerarquía dentro de 2FA

Pese a que son muchos los sistemas etiquetados como 2FA, las enormes diferencias existentes entre ellos hace imprescindible categorizarlos en función de su fiabilidad y resiliencia frente a los ataques.

SMS

• Interceptable mediante ataque a la señalización SS7.
• Se puede transferir sin consentimiento.
• Dependiente de una infraestructura que el usuario no controla.

Se puede considerar como un «mínimo aceptable» en ausencia de otras alternativas, nunca como estándar al que aspirar.

OTP mediante Email

OTP (One-Time Password o contraseña de un solo uso) es una clave numérica o alfanumérica generada dinámicamente que solo es válida para una única sesión. En éste caso, se remite al correo electrónico en lugar de al móvil. Ligeramente mejor que SMS porque no depende del operador, pero susceptible a todos los riesgos que presentan las cuentas de correo. Frecuente en servicios con poca inversión en seguridad.

Notificaciones Push

Aplicaciones como Duo Security o Microsoft Authenticator envían una notificación al móvil que el usuario confirma con un simple toque. Más cómodo que los códigos, pero susceptible a ataques de MFA fatigue (el atacante envía repetidas solicitudes de aprobación hasta que el usuario, por error o agotamiento, acepta una). Utilizado con éxito en el ataque a Uber de 2022.

TOTP (Time-based One-Time Password)

Se trata de códigos generados localmente cada 30 segundos a partir de un secreto compartido entre la app y el servicio. No dependen del operador ni de notificaciones externas. Eliminan por completo el riesgo de SIM swapping. Su única vulnerabilidad sería un ataque de Phishing en tiempo real:

El atacante opera como intermediario activo:

1. La víctima accede a una página falsa pero visualmente idéntica a la del servicio (tomemos por ejemplo un banco).
2. Introduce usuario + contraseña y el proxy los reenvía al banco real en milisegundos
3. El banco real responde: «envía el código TOTP».
4. La página falsa solicita ese código a la víctima.
5. La víctima lo introduce y el proxy lo reenvía al banco antes de que pasen los 30 segundos.
6. El banco autentica la sesión del atacante, no de la víctima.

Herramientas como Evilginx automatizan esto completamente; de forma que el atacante ni siquiera necesita actuar manualmente dado que el proxy captura la sesión autenticada (cookie de sesión) en tiempo real.

Llaves físicas FIDO2/WebAuthn

A día de hoy, el sistema más robusto a nivel usuario:

• La clave privada se genera dentro del dispositivo físico (una YubiKey por ejemplo) y está diseñada para que nunca pueda ser extraída ni exportada, ni siquiera por el propio usuario. Lo único que transmite el dispositivo es una firma criptográfica, no el secreto que la genera.
• La autenticación está vinculada al dominio exacto del servicio, lo que por diseño las hace resistentes al Phishing: aunque un atacante dirija al usuario a una página visualmente idéntica, la llave no responde porque el dominio no coincide.
• No hay código que interceptar.
• No hay notificación que aprobar por error.

El riesgo cuando no se dispone del móvil

Siempre que nuestro teléfono móvil forme parte de algún proceso relacionado con la seguridad, creo necesario abordar aquella situación donde sencillamente no podemos disponer de él. El escenario más frecuente no es un ataque sofisticado; es perder el teléfono, que lo roben o directamente no funcione. Si es el único lugar donde tenemos registrados los códigos TOTP, implica el quedarse sin acceso a todas las cuentas donde esté habilitado el servicio. Afortunadamente, la mitigación es mucho más sencilla que en el caso de las Passkeys. Eso sí, deben implementarse antes de que ocurra el problema:

Códigos de recuperación. La mayoría de servicios que ofrecen 2FA generan un conjunto de códigos de un solo uso al momento de activarlos. Copialos o descárgalos en un gestor de contraseñas. También se pueden escribir en papel y guardarlo en lugar seguro.

Nunca los almacenes en un dispositivo o aplicación que requiera utilizar el autenticador.

Registro en un segundo sistema. Servicios como Google, GitHub o Microsoft permiten registrar múltiples métodos de segundo factor. Registra el autenticador en dos dispositivos distintos. También puedes utilizar aplicaciones que dispongan de extensión de navegador (la mayoría lo soportan). O combinar una aplicación TOTP con una llave física como respaldo.

Exportación cifrada del la bóveda segura. Aplicaciones como Aegis, Proton o Bitwarden permiten exportar nuestra bóveda cifrada. Ése archivo, almacenado en un lugar seguro, permite restaurar todos los códigos en un dispositivo nuevo sin depender de ningún servicio externo.

Sincronización E2E. Ente Auth cifra y sincroniza los códigos entre dispositivos mediante cifrado de extremo a extremo. Si pierdes el móvil, los códigos están disponibles en otro dispositivo autenticado. La clave de recuperación generada al crear la cuenta es el único mecanismo de acceso en caso de pérdida de contraseña: debe guardarse con el mismo cuidado que los códigos de recuperación individuales.

El caso de las llaves físicas merece mención aparte: si la llave es el único 2FA registrado y se pierde, la recuperación depende exclusivamente de los códigos de respaldo. Por eso se recomienda registrar siempre al menos dos llaves físicas para cuentas críticas, o combinar una llave con una aplicación TOTP.

Sugerencias: guía de configuración

Aegis: Android, open source, control total

Aegis cifra la bóveda localmente con AES-256-GCM. No hay sincronización en la nube, lo que elimina un vector de ataque, pero introduce gestión activa: necesidad de efectuar copias de seguridad.

Pasos:

1. Instala Aegis desde F-Droid o Google Play.
2. Al crear la bóveda, activa el cifrado con contraseña (no solo con biometría).
3. Para añadir una cuenta: escanea el código QR del servicio al activar el 2FA, o introduce la clave manualmente.
4. Configura una exportación cifrada periódica y guarda el archivo en tu gestor de contraseñas o almacenamiento seguro.
5. Verifica que tienes los códigos de recuperación de cada servicio guardados por separado. Su formato de exportación es estándar y compatible con otras aplicaciones.

Ente Auth: Multiplataforma con cifrado E2E

Para quien necesita acceder a sus códigos desde Android, iOS, escritorio o navegador, Ente Auth ofrece sincronización cifrada de extremo a extremo. Es de código abierto y su arquitectura de cifrado está documentada públicamente.

Pasos:

1. Crea una cuenta en ente.io y descarga la app en todos tus dispositivos.
2. Durante el registro, guarda la clave de recuperación generada automáticamente, será el único mecanismo de acceso si pierdes el dispositivo y la contraseña.
3. Añade cuentas por QR o clave manual.
4. Verifica en Ajustes que la sincronización esté activa y autenticada en cada dispositivo.

Bitwarden Authenticator: Integración con el gestor de contraseñas

Si ya usas Bitwarden como gestor de contraseñas (uno de los más recomendables), Authenticator se integra fácilmente en el uso diario. Gratuita, de código abierto y disponible para Android e iOS.

Pasos:

1. Descarga Bitwarden Authenticator (independiente del gestor principal).
2. Añade cuentas por QR o clave manual.
3. Los códigos TOTP se generan localmente; la sincronización entre dispositivos requiere iniciar sesión con tu cuenta de Bitwarden.

A tener en cuenta: Absolutamente todas las guías/recomendaciones sobre Seguridad, plasman la necesidad de mantener separadas las aplicaciones de contraseñas y 2FA. Si alguien compromete el gestor, no obtiene automáticamente los códigos 2FA.

Llaves físicas: YubiKey y el estándar FIDO2

Una llave de seguridad física es el método más robusto disponible. YubiKey (Yubico) es el estándar de facto; existen alternativas como las Google Titan Key o las Nitrokey de código abierto.

Se basan en el estándar FIDO2/WebAuthn. Cuando el servicio solicita autenticación, el dispositivo genera una firma criptográfica válida únicamente para ese dominio exacto. Un sitio de phishing, aun estéticamente idéntico al original, no puede obtener una respuesta válida porque el dominio no coincide.

Configuración en un servicio compatible (ejemplo: GitHub):

1. Ve a Configuración -> Contraseña y autenticación -> Llaves de seguridad.
2. Conecta la YubiKey por USB o NFC.
3. Pulsa el botón físico de la llave cuando el navegador lo solicite.
4. Registra siempre una segunda llave como respaldo, o una aplicación 2FA.

A fecha de hoy, no todos los servicios soportan FIDO2. El uso en el móvil requiere que la llave tenga NFC o conector USB-C compatible. Para servicios que no lo admiten, el TOTP sigue siendo la mejor alternativa.

Qué hacer cuando el servicio solo ofrece SMS

Algunos servicios, especialmente en banca, administración pública y plataformas heredadas, no ofrecen otra opción. En éstos casos, todo pasa por tratar de mitigar al máximo las opciones de ataque:

• Usa un número secundario, idealmente una SIM prepago dedicada que no esté vinculada a tu identidad pública ni a tus cuentas principales.
• Activa con tu operador cualquier capa adicional disponible: PIN de portabilidad, verificación reforzada para cambios de SIM, bloqueo de transferencia de número.
• Nunca uses el mismo número para recuperación de cuenta, SMS 2FA y contacto público.

Son medidas paliativas, no soluciones.

Tabla comparativa

Conclusiones

El doble factor de autenticación, si bien no es una garantía absoluta, sí supone una diferencia real frente al combo de usuario + contraseña habitual. Por contra, añade un elemento más a gestionar, sea mediante una nueva aplicación o mediante un dispositivo físico. Y ése es precisamente el factor determinante a la hora de incorporarlo o no a nuestro flujo de seguridad.

Si por cualquier motivo, se nos hace complicado gestionar las contraseñas de forma habitual, tal vez no sea buena idea añadir 2FA de forma generalizada.

Nuestro objetivo de seguridad ha de ser aquél, que seamos capaces de gestionar tanto en el día a día, como ante situaciones de emergencia.

De nada sirve implicarse con los mejores métodos, servicios y aplicaciones; si el resultado final es perder el acceso a nuestras cuentas por algún error en la gestión. Una pérdida de acceso, que en algunos casos, no puede ser revertida.