Prompt y contexto
Un SaaS de bajo riesgo desea que los usuarios ingresen una dirección de correo electrónico y reciban un enlace de inicio de sesión de un solo uso. Diseña los flujos de solicitud, entrega, verificación, establecimiento de sesión, revocación y auditoría. Cubre escenarios de un buzón de correo comprometido, enlaces reenviados, precarga de correo (mail prefetch), repetición, abuso de límites de tasa (rate abuse) y acciones de alto riesgo.
Qué está evaluando el entrevistador
- Si utilizas tokens impredecibles, de corta duración y de un solo uso.
- Si previenes la enumeración de cuentas, la fuga en registros (logs) y la verificación por fuerza bruta.
- Si distingues entre conveniencia, nivel de garantía (assurance) y resistencia al phishing.
- Si las sesiones, la revocación, las notificaciones, la auditoría y los mecanismos de respaldo están completos.
Preguntas para aclarar antes de responder
Confirma el riesgo del negocio, el estado del correo electrónico verificado, el comportamiento multidispositivo, la vida útil del enlace, el proveedor de correo, MFA y las operaciones de alto riesgo. Los pagos, los cambios de privilegios y los datos confidenciales requieren autenticación resistente al phishing o autenticación adicional, no el correo electrónico como único factor de alta seguridad.
Estructura de respuesta en 30 segundos
Genera un token aleatorio de alta entropía y almacena solo su hash, propósito, usuario, expiración y estado de consumo. Devuelve la misma respuesta tanto para direcciones existentes como desconocidas y limita la tasa de solicitudes (rate-limit). Verifica a través de HTTPS, consume el token de forma atómica, crea una sesión de corta duración y rota su identificador. Permite un solo uso, audita fallos y dispositivos inusuales, y revoca cuando sea necesario. La seguridad de un magic link hereda los riesgos del buzón de correo y del canal del navegador, por lo que no es automáticamente resistente al phishing ni adecuada para todos los niveles de garantía de NIST.
Análisis detallado paso a paso
1. Generación y almacenamiento
Utiliza un valor aleatorio criptográficamente seguro como parámetro de URL de un solo uso; almacena su hash en lugar del texto en plano. Registra el propósito, el usuario, las marcas de tiempo de creación y expiración, el momento de consumo y el contexto de la solicitud. Compara los hashes en tiempo constante y limita los intentos.
2. Solicitud y verificación
Devuelve el mismo mensaje, ventana de tiempo de respuesta y estado para cada correo electrónico con el fin de evitar la enumeración. Limita la tasa por IP, dirección, dispositivo y presupuesto global, con una cuota de envío de correos. La verificación debe marcar el token como consumido dentro de una transacción o actualización condicional atómica, evitando que dos clics simultáneos lo reutilicen.
3. Controles de sesión y de riesgo
Tras el consumo, rota el identificador de sesión, establece una cookie segura y notifica al usuario sobre el dispositivo y la ubicación. Los sistemas de precarga de correo y los escáneres pueden visitar un enlace primero; utiliza una página de confirmación intermedia y una acción explícita del usuario. Exige reautenticación, MFA o WebAuthn para operaciones sensibles en lugar de convertir un enlace en una credencial privilegiada de larga duración.
Respuesta de ejemplo de alta calidad
Defino los magic links como un factor conveniente para accesos de bajo riesgo, no como un autenticador universal resistente al phishing. Tras una solicitud, el servicio utiliza un CSPRNG, almacena únicamente un hash, propósito, expiración y estado de consumo, y devuelve el mismo resultado para cada dirección. El verificador busca el hash a través de HTTPS, lo marca atómicamente como consumido, rota el ID de sesión, establece una cookie segura y registra un evento de auditoría. Los enlaces son de corta duración y revocables; sus URL deben mantenerse fuera de los logs y de las herramientas de analítica. Para gestionar la precarga, muestra una página de confirmación y exige un clic deliberado. Para el reenvío y los múltiples dispositivos, define si se permite un solo consumo y cómo notificar al propietario de la cuenta. Los pagos y los cambios de privilegios utilizan MFA o WebAuthn. Las pruebas cubren repetición, clics concurrentes, enumeración, límites de tasa, filtración de correos, dispositivos anómalos y revocación.
Errores comunes
- Almacenar tokens en texto en plano en bases de datos o logs.
- No consumir el token de forma atómica, permitiendo la repetición concurrente.
- Devolver un error diferente para una dirección desconocida, facilitando la enumeración.
- Calificar los magic links como intrínsecamente resistentes al phishing o equivalentes a una clave de hardware.
- Canjear un enlace expirado por una sesión de larga duración u omitir la notificación y la revocación.
Preguntas de seguimiento y respuestas
¿Qué ocurre con la precarga de los clientes de correo?
No completes el inicio de sesión en una petición GET. Muestra una página de confirmación, consume el token únicamente tras una acción explícita del usuario y distingue la telemetría de precarga de un clic real.
¿Cuánto tiempo debe vivir un token?
Elige una ventana corta a partir de los márgenes de riesgo y retraso del correo, y luego monitorea las tasas de repetición y de tokens no utilizados. Tras la expiración, emite un nuevo token en lugar de extender el anterior.
¿Por qué no usarlo para administradores o aprobación de pagos?
Los canales de buzón de correo pueden ser reenviados, secuestrados o ser blanco de phishing, y el NIST separa ciertos usos de confirmación por correo electrónico de la autenticación de alta seguridad. Las acciones de alto riesgo necesitan autenticación resistente al phishing, vinculación de transacciones (transaction binding) y notificación independiente.