Por qué la verificación de email importa más de lo que crees

La verificación de email cumple tres objetivos principales. Primero confirma que el usuario controla realmente la dirección proporcionada — los errores tipográficos como [email protected] son sorprendentemente frecuentes. Segundo reduce la creación masiva de cuentas automatizadas por bots que usan direcciones falsas o desechables. Tercero — y este punto se subestima más — una dirección verificada es un requisito de seguridad previo para el restablecimiento de contraseña. Sin verificación, un atacante podría registrar la dirección de otra persona y activar un email de restablecimiento hacia ella. El OWASP Authentication Cheat Sheet cubre estos riesgos en detalle.

El flujo de verificación completo paso a paso

El protocolo de transporte de email está definido en RFC 5321 — pero las decisiones a nivel de aplicación dependen completamente del desarrollador. Cada paso importa:

1. El usuario envía el formulario de registro. Validar el formato de email en el servidor — no solo en el cliente.
2. Generar un token criptográficamente aleatorio. No un UUID, no un ID secuencial, no un timestamp — verdadera aleatoriedad criptográfica con al menos 32 bytes de entropía.
3. Almacenar el hash del token en la base de datos. Guardar el hash SHA-256 del token, no el token en bruto — junto con el ID de usuario, timestamp de creación, tiempo de expiración y un flag "usado".
4. Enviar el email de verificación. El enlace contiene el token en bruto como parámetro de consulta. Usar siempre HTTPS.
5. El usuario hace clic en el enlace. El servidor recibe el token en bruto en la cadena de consulta.
6. Validar el token. Hashear el token entrante, buscar la coincidencia en la base de datos, verificar expiración y el flag "usado".
7. En caso de éxito: marcar el email como verificado, marcar el token como usado, iniciar sesión del usuario.
8. En caso de fallo: mostrar un mensaje de error específico y accionable con un enlace para solicitar un nuevo email.

Generación segura de tokens

El error más común es usar UUID v4 como token de verificación. Los UUID son buenos para identificadores de base de datos, pero no están diseñados como tokens de seguridad. El enfoque correcto: usar el generador de números aleatorios criptográficos de tu runtime. En Node.js: crypto.randomBytes(32).toString('hex'). En Python: secrets.token_urlsafe(32). En .NET: RandomNumberGenerator.GetBytes(32). El OWASP Authentication Cheat Sheet recomienda al menos 32 bytes (256 bits) de entropía.

Para el almacenamiento: guardar el hash SHA-256 en la base de datos y enviar el token en bruto en el enlace del email. En la validación, hashear el token entrante y comparar con el hash almacenado. Si un atacante accede a la base de datos, los hashes son inútiles. Usar comparaciones en tiempo constante: crypto.timingSafeEqual() en Node.js, hmac.compare_digest() en Python.

Expiración de tokens — los detalles correctos

24 a 48 horas es el estándar para la expiración de tokens. Suficientemente largo para que un usuario que se registra de noche pueda verificar su email a la mañana siguiente. Suficientemente corto para limitar la ventana de uso de un token robado. Indicar claramente la expiración en el email: "Este enlace de verificación expira en 24 horas."

Probar el flujo de verificación correctamente

Cada cambio en el flujo de verificación debe probarse con un email real a una bandeja de entrada real. Abre un correo temporal, copia la dirección en el formulario de registro, crea una cuenta de prueba y observa cómo llega el email de verificación en tiempo real. Esto prueba definitivamente que el email se entrega realmente — no solo que la API del proveedor lo acepta.

• Camino feliz: registro, recepción del email, clic en el enlace, cuenta verificada
• Token expirado: establecer la expiración en el pasado en la base de datos, hacer clic en el enlace — mensaje de error claro con opción de reenvío
• Token ya usado: hacer clic en el mismo enlace dos veces — mensaje "ya verificado" en lugar de error
• Token manipulado: cambiar el valor del token en la URL — mensaje de error claro
• Flujo de reenvío: solicitar nuevo email, confirmar nuevo enlace, verificar que el enlace antiguo ya no funciona

Autenticación de email: SPF, DKIM y DMARC

Sin autenticación de email correcta, los emails de verificación van al spam. SPF autoriza los servidores de envío mediante un registro DNS TXT. DKIM añade una firma criptográfica. DMARC define la política cuando SPF o DKIM fallan. Usar MXToolbox para verificar las tres configuraciones. Consultar la documentación sobre autenticación de email en tu proveedor de envío.

Errores comunes a evitar

• No invalidar el token después del uso. Siempre establecer el flag "usado" y verificarlo en cada validación.
• Enviar emails de bienvenida antes de la verificación. Activar secuencias de onboarding solo tras verificación confirmada.
• No limitar las solicitudes de reenvío. Limitar reenvíos por dirección a por ejemplo tres por hora.
• Enviar enlaces de verificación por HTTP. Usar siempre HTTPS — sin excepción.
• No registrar eventos de verificación. Cuándo se creó, envió y utilizó el token — esencial para el diagnóstico.
• Usar el mismo token para múltiples propósitos. Tokens separados para verificación, restablecimiento de contraseña y cambio de email.