MFA de acceso remoto: TOTP, push, passkeys y tokens hardware

Conoces el problema: las contraseñas son phisheadas, reutilizadas o forzadas por fuerza bruta, y una sesión de acceso remoto es el premio. La autenticación multifactor (MFA) es la solución obvia — pero no todos los segundos factores detienen los mismos ataques. Este artículo compara TOTP, notificaciones push, passkeys (FIDO2) y llaves hardware para que puedas elegir lo que realmente reduce el riesgo en tu flota de acceso remoto.

Resumen rápido de amenazas — qué debe detener la MFA

Antes de comparar los métodos, hay que ser explícito sobre los modelos de atacante. Distintos métodos de MFA bloquean distintas capacidades. En acceso remoto me interesan los atacantes que pueden:

• Robar o adivinar contraseñas (credential stuffing, contraseñas filtradas).
• Hacer phishing a los usuarios con una página de inicio de sesión falsa y capturar códigos o tokens de sesión en tiempo real.
• Suplantar o interceptar tráfico de red (mitm) o controlar una sesión VPN.
• Controlar el dispositivo del usuario (malware que lee autenticadores, o una sesión ya establecida).
• Robar físicamente un dispositivo (teléfono o token hardware) o realizar SIM swaps (relevante para SMS).
• Explotar la recuperación de cuentas o las anulaciones del help‑desk para eliminar la MFA.

Si quieres un mapeo más profundo de estas amenazas específicamente para productos de escritorio remoto, consulta ¿Es seguro el escritorio remoto? Un modelo de amenazas honesto y Seguridad en escritorio remoto: lo que necesitas saber.

TOTP (time‑based one‑time passwords): qué es y qué ataques detiene

TOTP (RFC 6238) genera códigos numéricos cortos — comúnmente de 6 dígitos que cambian cada 30 segundos — usando un secreto compartido almacenado en el servidor y en el autenticador (app o token). Google Authenticator, Authy, FreeOTP y muchos tokens hardware usan TOTP.

• Stops: credential stuffing y reuso de contraseñas. Si un atacante solo tiene la contraseña, aún necesita el TOTP actual.
• Partially stops: fuerza bruta automatizada — como los códigos son cortos, los límites de tasa siguen siendo esenciales.
• Does not stop: phishing en tiempo real o man‑in‑the‑middle (MiTM). Un atacante que tiene una página de login puede pedirle a la víctima el TOTP actual y usarlo de inmediato para completar el inicio de sesión. También falla si el dispositivo del usuario está comprometido y el secreto es exfiltrado.

Notas operativas: TOTP es simple y ampliamente soportado. Pero el enrolamiento de secreto compartido (códigos QR) debe protegerse: una vez que entregas el secreto a un usuario, cualquiera con ese secreto puede generar códigos para siempre. Las políticas de respaldo y recuperación (re‑provisión cuando se pierde un teléfono) son donde muchas organizaciones debilitan la seguridad al depender en exceso de reinicios por help‑desk.

Notificaciones push: conveniencia con riesgos de ingeniería social

La MFA por push envía una notificación a un dispositivo registrado pidiendo al usuario aprobar o denegar un intento de inicio de sesión. Las implementaciones varían: algunas incluyen detalles de la transacción (IP, nombre de la app), otras solo muestran un mensaje "Aprobar". El servidor emite un challenge y el dispositivo lo firma o lo confirma, luego el servidor otorga la sesión.

• Stops: robo de credenciales por sí solo — un atacante que solo tiene la contraseña no puede completar el inicio de sesión sin la aprobación.
• Partially stops: ataques automatizados y algunos escenarios MiTM si el push está ligado a un challenge del servidor.
• Does not reliably stop: ingeniería social dirigida en tiempo real ("aprueba el inicio de sesión para continuar") y ataques de fatiga por "push‑bombing". Si un atacante hace phishing a un usuario y simultáneamente intenta el inicio de sesión real, muchos usuarios simplemente aprueban para detener el bombardeo. Además, el push sigue dependiendo de la integridad del dispositivo; un teléfono comprometido que aprueba automáticamente o está controlado por malware derrota este factor.

Punto práctico: el push tiene alta conversión y es bueno para el personal general, pero no lo trates como resistente al phishing a menos que la implementación incluya vinculación de origen/transacción y la organización aplique formación al usuario y comprobaciones contextuales (ubicación, postura del dispositivo).

Passkeys (FIDO2 / WebAuthn) — resistencia real al phishing cuando se implementan correctamente

Passkeys es el nombre amigable para las credenciales FIDO2/WebAuthn. Son credenciales de clave pública creadas por cada relying party (tu servicio de acceso remoto). La clave privada permanece en el autenticador (plataforma o roaming); el autenticador firma un challenge que incluye el identificador del relying party. Debido a que la firma está ligada al origen del relying party, un sitio de phishing no puede reutilizarla en el sitio real.

• Stops: phishing, MiTM que dependa de la captura de credenciales, replay de credenciales y muchos ataques automatizados. Si el autenticador es un elemento seguro (TPM, Secure Enclave, o un token hardware que implemente FIDO2), el material de clave no es extraíble.
• Partially stops: ataques donde el atacante controla el dispositivo mientras el usuario está presente — p. ej., si malware en el host puede disparar aprobaciones o inscribir nuevas credenciales vía un flujo de recuperación de cuenta comprometido.
• Does not stop: robo físico cuando el autenticador es inseguro y no está protegido por PIN/biometría, o abuso de recuperación de cuenta donde el help‑desk puede eliminar la llave sin controles adecuados.

En la práctica, FIDO2/passkeys son el único segundo factor estándar, ampliamente disponible y resistente al phishing. Las passkeys de plataforma (Windows Hello, Touch ID/Face ID) son convenientes, y las llaves hardware roaming que implementan FIDO2 (YubiKey con FIDO2, Nitrokey FIDO) ofrecen las mismas garantías con mayor separación física.

Llaves hardware: tokens OTP vs tokens FIDO2 — elige con cuidado

Los tokens hardware vienen en dos variantes: tokens de contraseña de un solo uso (HOTP/TOTP hardware tokens) y tokens FIDO2/WebAuthn. Ambos tienen pros y contras.

• HOTP/TOTP hardware tokens: dispositivos pequeños y baratos que muestran códigos numéricos. Heredan las mismas debilidades que el TOTP en software: modelo de secreto compartido, vulnerables al phishing en tiempo real si el atacante solicita el código y lo usa de inmediato.
• FIDO2 hardware tokens: usan criptografía de clave pública y son resistentes al phishing por las razones descritas arriba. A menudo requieren un toque o PIN en el token, lo que protege contra el uso no autorizado si el token es robado.

Compensaciones operativas: los tokens FIDO2 son preferibles donde importa la resistencia al phishing. Cuestan más, requieren inventario y políticas de gestión de claves (emisión, reporte de pérdida, respaldos). Los tokens TOTP son baratos y mejor que nada, pero trátalos como un paso por encima de las contraseñas, no como una solución milagro.

Cómo cada método se aplica a escenarios comunes de ataque de acceso remoto

Mapeos concretos facilitan la elección. Aquí hay ataques comunes de acceso remoto y qué factores los bloquean.

• Atacante con solo la contraseña (fuga de credenciales): TOTP, push, passkeys y tokens hardware bloquean el acceso.
• Sitio de phishing en tiempo real que actúa como proxy del login: TOTP y push probablemente serán eludidos porque el atacante puede retransmitir el código/push, a menos que el push incluya detalles de transacción sólidos y el usuario los verifique. FIDO2/passkeys bloquean esto porque la firma está ligada al origen.
• Dispositivo de usuario comprometido (malware en el PC usado para iniciar la sesión remota): MFA ayuda solo si el atacante no puede usar también el dispositivo MFA. Si el malware puede leer secretos TOTP, interceptar aprobaciones push o disparar una passkey de plataforma sin presencia del usuario, la MFA puede fallar. Las llaves hardware físicas con toque/PIN ofrecen mayor protección aquí.
• Abuso del help‑desk o la recuperación de cuentas: Cualquier MFA puede ser eludida si tus procesos de recuperación permiten eliminar factores sin autenticación fuerte. Endurece los flujos de recuperación y registra los cambios cuidadosamente.

Recomendaciones de despliegue para acceso remoto

Elegir el "mejor" factor depende de la tolerancia al riesgo, el presupuesto y la capacidad operativa. Para acceso remoto (herramientas de soporte, consolas de administración, gateways RDP) recomiendo la siguiente línea base:

• Requerir MFA resistente al phishing (FIDO2/passkeys o tokens hardware FIDO2) para cuentas con privilegios y operadores de soporte remoto. Estos son los roles de mayor riesgo.
• Permitir push o TOTP para el personal general, pero solo con controles compensatorios: comprobaciones de postura del dispositivo, verificaciones de IP/geolocalización, sesiones de corta duración y alertas por actividad anómala.
• Aplicar recuperación de cuenta estricta: reinscripción en varios pasos que requiera pruebas (dispositivo, comprobaciones de identidad) y registrar cada acción de recuperación.
• Mantener factores de respaldo: emitir un número limitado de tokens de recuperación y requerir verificación secundaria antes de reemplazar una llave roaming perdida.

Operativamente, recuerda que autohospedar la infraestructura MFA solo vale la pena cuando es estrictamente necesario — por cumplimiento, redes aisladas o reglas estrictas de residencia de datos. Los servicios gestionados (incluido el managed relay de Tenvo) suelen costar menos si cuentas parches, renovación de certificados, custodia de claves y tiempo on‑call. Tenvo’s managed relay es nuestra recomendación por defecto: ofrecemos clientes nativos para macOS, Windows y Linux, un cliente web en beta pública y un managed relay multi‑región. Los planes son Free $0, Lite $2.99/mo y Pro $7.99/mo — la opción administrada te da redundancia y cero mantenimiento de relays.

Si te autohospedas, acepta la sobrecarga operativa descrita en Self-Hosted Remote Desktop: Why, How, and What Breaks y asegura los canales de recuperación de forma agresiva.

Realidades operativas — respaldos, enrolamiento, fraude y experiencia de usuario

Un buen diseño de MFA equilibra seguridad con operaciones en vivo. Algunas notas pragmáticas:

• Seguridad del enrolamiento: Protege el paso inicial de vinculación. Si el enrolamiento no está autenticado o solo está protegido por el mismo usuario/contraseña, un atacante que pueda adivinar credenciales puede provisionarse un factor. Requiere un segundo canal para el enrolamiento (confirmación por correo a una dirección corporativa, aprobación de un administrador).
• Respaldos y recuperación: No envíes secretos en texto plano por correo. Para passkeys, ofrece flujos alternativos de recuperación (múltiples llaves por cuenta, llaves de recuperación en custodia con controles de acceso estrictos). Para TOTP, desaconseja capturas de pantalla de códigos QR y aplica reemitidos con tiempo limitado.
• Controles del help‑desk: Haz que la revocación y reemisión sean auditables y multipartes para cuentas de alto privilegio.
• Registro y alertas: Registra fallos de MFA, nuevos enrolamientos de factores y eventos de recuperación. Conéctalos a tu SIEM y exige revisión humana ante patrones anómalos.
• Experiencia de usuario: Las passkeys de plataforma reducen la carga del help‑desk. El push es lo más sencillo para usuarios no técnicos, y TOTP es útil donde los dispositivos no pueden recibir pushes.

Si quieres una lista corta y práctica para configurar acceso remoto rápidamente manteniendo la MFA sensata, consulta Cómo configurar acceso remoto en 60 segundos y nuestra guía sobre Cómo dar acceso remoto a alguien de forma segura.

Resumen: elige MFA defendible y resistente al phishing para accesos sensibles

Versión corta:

• TOTP es mejor que nada pero falla frente a phishing en tiempo real y cualquier atacante que pueda proxyar una sesión.
• Push añade conveniencia pero es vulnerable a ingeniería social y fatiga de aprobación a menos que se apliquen detalles de transacción y contexto.
• FIDO2/passkeys (incluyendo tokens hardware FIDO2) son el único estándar, ampliamente disponible, que resiste el phishing de forma fiable cuando se despliega correctamente.
• Los tokens hardware que implementan FIDO2 ofrecen la protección más fuerte para cuentas de alto riesgo; mantén procesos estrictos de recuperación y respaldo.
• La sobrecarga operativa (enrolamiento, help‑desk, respaldos) es el coste real — y un relay/servicio gestionado suele reducir ese coste en comparación con autohospedar, a menos que tengas un requisito por escrito para autohospedar.

Usa MFA resistente al phishing (passkeys o tokens FIDO2) para administradores y operadores de soporte remoto, mantiene push/TOTP como alternativas pragmáticas para el personal general y endurece la recuperación y el enrolamiento para que la MFA no pueda ser eliminada de forma trivial.

Si quieres un camino de implementación que balancee coste operativo y seguridad, Tenvo’s managed relay elimina muchas de las cargas de costes operativos: clientes nativos macOS/Windows/Linux, cliente web en beta pública, managed relay multi‑región y planes Free $0 / Lite $2.99/mo / Pro $7.99/mo. Los managed relays también simplifican la aplicación de MFA en dispositivos distribuidos en comparación con un único relay autohospedado.

¿Listo para probar? Descarga el cliente y habilita segundos factores fuertes para tus cuentas críticas: Descargar Tenvo.