Aplicaciones 2FA seguras: qué mirar antes de elegir

Ese dato enmarca la elección de una aplicación de autenticación en dos factores: la pregunta no es si conviene añadir un segundo factor —la respuesta es afirmativa—, sino qué tipo de aplicación 2FA reduce la superficie de ataque sin introducir nuevos riesgos operativos. La oferta actual combina alternativas de código cerrado con históricas limitaciones de privacidad y un conjunto creciente de proyectos de código abierto que priorizan el cifrado local y la portabilidad de los tokens. Comparar sus parámetros técnicos antes de instalar la primera opción que aparezca en la tienda de aplicaciones es la decisión que determina el nivel real de protección.

El estándar TOTP y la debilidad estructural del SMS

La autenticación en dos factores se apoya en tres categorías: algo que sabes (contraseña), algo que tienes (dispositivo o token físico) y algo que eres (biometría). Las aplicaciones 2FA más seguras se inscriben en la segunda categoría mediante el estándar TOTP (Time-based One-Time Password), definido en la RFC 6238 del IETF.

TOTP genera un código de seis dígitos que rota cada 30 segundos a partir de un secreto compartido y la hora local del dispositivo. El cálculo se ejecuta íntegramente en el cliente: la aplicación no contacta con el servidor del servicio autenticado para validar el código, lo que elimina la dependencia de la cobertura móvil, de la red de datos y de la infraestructura SMS de la operadora.

TOTP ejecuta el cálculo en el dispositivo. Sin red, sin SMS, sin telemetría: solo el reloj y el secreto compartido.

El 2FA por SMS, todavía ofrecido por numerosos servicios, presenta debilidades documentadas:

• SIM swapping: el atacante duplica la SIM del usuario tras un proceso de ingeniería social con la operadora y recibe el código en su propio dispositivo.
• Interceptación SS7: la señalización de la red telefónica presenta vulnerabilidades estructurales que permiten redirigir mensajes entre operadores.
• Phishing en tiempo real: los kits de phishing capturan el código SMS antes de que expire su validez temporal.

Frente a estos vectores, el token TOTP local reduce la superficie de ataque al dispositivo físico del usuario y al secreto criptográfico almacenado en él. Ningún intermediario de telecomunicaciones participa en el flujo. El 2FA por SMS sigue siendo preferible a la ausencia total de segundo factor, pero es la opción menos robusta entre las disponibles.

Código abierto frente a código cerrado: el valor de la auditoría

La diferencia entre una aplicación 2FA de código abierto y una de código cerrado no es estética: condiciona la verificabilidad del producto y el modelo de confianza.

En una aplicación de código cerrado, el usuario se apoya en la política de seguridad declarada por el proveedor sin posibilidad de inspeccionar el código fuente, los algoritmos criptográficos implementados ni el tratamiento real de los datos locales y en tránsito. Google Authenticator y Microsoft Authenticator pertenecen a esta categoría. No procede calificarlas de inseguras por defecto, pero presentan limitaciones concretas en materia de transparencia: la sincronización en la nube no utiliza, por defecto, cifrado de extremo a extremo (E2EE) sobre los tokens almacenados, lo que significa que el proveedor técnicamente puede acceder a las claves TOTP sincronizadas.

Una aplicación de código abierto como Aegis, Ente Auth o Proton Authenticator publica el código fuente bajo licencias que permiten:

1. Auditoría independiente por terceros especializados.

2. Reproducibilidad de las compilaciones (reproducible builds).

3. Verificación criptográfica del binario distribuido frente al código fuente.

El código abierto no equivale a software libre de fallos. Una auditoría técnica activa sigue siendo necesaria para validar la implementación, y un proyecto de código abierto sin revisores activos ofrece garantías formales sin respaldo sustantivo. Aun así, el modelo desplaza la confianza del proveedor hacia la comunidad técnica que revisa el código y reduce la dependencia de la continuidad comercial del fabricante.

Cifrado local y portabilidad: la soberanía sobre los tokens

Una aplicación 2FA que almacena los secretos TOTP en texto plano dentro del dispositivo es, en la práctica, una base de datos de credenciales expuesta a cualquier malware con acceso al almacenamiento. El parámetro decisivo es el cifrado, evaluado en tres planos:

• Cifrado en reposo: el fichero de tokens debe almacenarse cifrado con AES o un algoritmo equivalente, protegido por una clave maestra derivada de una contraseña o PIN definidos por el usuario.
• Cifrado en tránsito: si la aplicación ofrece sincronización entre dispositivos, la conexión debe establecerse sobre TLS 1.3 o superior, y los datos sincronizados deben viajar con E2EE para impedir que el proveedor pueda leerlos.
• Cifrado en la copia de seguridad: la exportación a un fichero de respaldo debe permitir cifrado local con contraseña, sin delegación en la nube del fabricante.

Aegis cumple los tres vectores: las copias de seguridad se generan cifradas en local, la aplicación se protege con PIN o biometría (huella dactilar o reconocimiento facial) y no requiere cuenta en línea para funcionar. Ente Auth y Proton Authenticator añaden sincronización cifrada de extremo a extremo entre dispositivos; Ente Auth aplica una arquitectura de cifrado cliente que impide al servidor acceder al contenido incluso bajo requerimiento legal.

La portabilidad es la otra cara de la soberanía sobre los tokens. Authy, de Twilio, dificulta la migración al no permitir la exportación directa de las claves almacenadas; la versión de escritorio se retiró en 2024, lo que reduce aún más las opciones de recuperación ante pérdida del dispositivo. Cualquier aplicación 2FA que no permita exportación de tokens bloquea al usuario en su propio proveedor y crea un riesgo operativo crítico: si el fabricante cierra el servicio o modifica sus condiciones, los códigos quedan inaccesibles.

Sin exportación local de tokens, el usuario no es dueño de sus claves: las alquila al proveedor.

Aegis, Ente Auth y 2FAS: parámetros comparados

La siguiente tabla resume los parámetros técnicos de las tres alternativas de código abierto más consolidadas en el ecosistema actual:

La lectura técnica de la tabla arroja tres perfiles diferenciados:

• Aegis prioriza el almacenamiento estrictamente local y la autonomía del usuario. No hay cuenta, no hay servidor, no hay telemetría. La contrapartida es la ausencia de sincronización automática entre dispositivos, lo que exige disciplina en las copias de seguridad locales.
• Ente Auth incorpora sincronización cifrada de extremo a extremo entre dispositivos sin sacrificar la portabilidad de los tokens. El usuario asume el coste de una cuenta en la infraestructura de Ente, aunque el modelo de cifrado impide al operador acceder al contenido.
• 2FAS ocupa un punto intermedio: permite sincronización opcional a través de Google Drive o iCloud con cifrado de cliente, sin imponer cuenta propia. La exportación a JSON facilita migraciones entre aplicaciones sin dependencia del proveedor.

Resiliencia operativa: cómo evitar el bloqueo de acceso

Una aplicación 2FA mal configurada puede convertirse en un punto único de fallo. Las tres estrategias de mitigación operativa son:

1. Copia de seguridad cifrada local. Tras la configuración inicial de los tokens, exportar a un fichero cifrado con contraseña robusta y almacenar el respaldo en un soporte separado del dispositivo principal: disco cifrado, gestor de contraseñas con vault protegido, o incluso papel en lugar seguro si se imprime el QR como URI otpauth.

2. Dispositivo secundario de respaldo. Registrar los tokens en un segundo dispositivo (tableta o teléfono antiguo) que permanezca actualizado y en lugar seguro. Aegis y 2FAS admiten esta práctica sin requerir cuenta de usuario.

3. Varios métodos de recuperación en cada servicio. Los proveedores de identidad —Google, GitHub, entidades bancarias, plataformas SaaS— suelen permitir registrar varios factores simultáneos. Añadir una llave de seguridad física compatible con WebAuthn como segundo factor alternativo reduce la dependencia exclusiva del TOTP móvil.

El error más frecuente consiste en configurar el segundo factor y no probar el flujo de recuperación hasta el momento en que se pierde el acceso al dispositivo. La auditoría periódica —generar un código desde la aplicación, verificar la copia de seguridad en un dispositivo limpio, restaurar desde el respaldo— debe integrarse en el mantenimiento habitual de seguridad.

Criterios de selección e impacto a corto y medio plazo

A corto plazo, la migración desde SMS y desde aplicaciones de código cerrado sin E2EE reduce la superficie de ataque vinculada a credenciales comprometidas, que según las cifras de IBM representan el 10 % de las filtraciones globales. La verificación de que la aplicación cumple cinco criterios técnicos —código abierto, cifrado del almacén local, copia de seguridad cifrada local, exportación en formato estándar, protección de acceso con PIN o biometría— cierra el ciclo básico de protección.

A medio plazo, la tendencia del sector apunta a WebAuthn y a las llaves de seguridad físicas (YubiKey, Token2 y compatibles FIDO2) como segundo factor preferente. Estas llaves materializan el factor "algo que tienes" sin depender de un dispositivo con TOTP, mitigan el phishing de sesión y son aceptadas por la mayoría de grandes proveedores de identidad. Para usuarios con alta exposición, la combinación de llave física como factor principal y aplicación TOTP local como respaldo ofrece la mayor resiliencia disponible fuera de los sistemas corporativos con HSM.

Cualquier aplicación 2FA que cumpla los cinco criterios técnicos ofrece una base sólida para reducir el riesgo de compromiso de credenciales. Ninguna herramienta sustituye a la disciplina operativa: la aplicación 2FA más segura es aquella cuyas copias de seguridad se verifican periódicamente y cuyos tokens permanecen portables entre proveedores. La decisión de hoy —código abierto, cifrado local, exportación verificable— condiciona la capacidad de recuperación de mañana.