Patrones de Seguridad: Recuperación de Contraseña y Endpoints

Este documento sirve como base de conocimiento y aprendizaje sobre las mejores prácticas de seguridad aplicadas en flujos de recuperación de contraseña, usando como referencia una arquitectura basada en [[Flet]] y [[Arquitectura Hexagonal]].

1. El Mito de los Endpoints GET en Flet

En arquitecturas tradicionales (como un MVC en PHP o un server-side rendering tradicional), enviar un formulario con datos sensibles a través de un endpoint HTTP GET es una vulnerabilidad crítica, ya que la contraseña quedaría expuesta en la URL (ej: /api/change?pwd=secreta), guardándose en los logs del servidor y del historial del navegador.

Por qué en Flet esto no aplica para el submit:

• Flet es un framework que se comunica a través de WebSockets.
• El Token en el GET: Es completamente estándar y seguro que el link enviado por email contenga el token en la URL (ej: /reset-password?token=abc...). Esto es necesario para que el enlace sea "clickeable".
• El Submit (POST equivalente): Cuando el usuario ingresa la nueva contraseña en la UI de Flet y presiona "Guardar", Flet no realiza un request HTTP GET. Empaqueta el input de la UI y lo transmite por el túnel seguro (WSS - WebSocket Secure) hacia el backend (AuthController). La contraseña nueva nunca se expone en la URL ni en logs de enrutamiento web.

2. Arquitectura Hexagonal y Resend API

Para el envío de correos, es fundamental no acoplar el controlador de autenticación con la librería de terceros (en este caso, la API de Resend).

Implementación Correcta:

• Definir un Protocolo (Interfaz): Crear un EmailService(Protocol) abstracto.
• Implementar el Adaptador: Crear un ResendEmailService que cumpla con esa interfaz e integre el SDK oficial.
• Inyección de Dependencias: El servicio de dominio (AuthService) solo conoce el protocolo, ignorando si por detrás opera Resend, SendGrid o un Mock para Testing.

Relacionado: [[Arquitectura Hexagonal]], [[Inyección de Dependencias]], [[Protocol]]

3. Prácticas Avanzadas de Seguridad (Cero Deuda Técnica)

Al auditar flujos de [[Autenticación]], la ausencia de deuda técnica se evidencia cuando se implementan estos tres escudos:

A. Protección contra Enumeración de Correos

• El Problema: Si la API devuelve "Email no encontrado" cuando un atacante ingresa un correo aleatorio, y "Email enviado" cuando el correo es real, el atacante puede descubrir qué usuarios están registrados en la plataforma.
• La Solución: El endpoint/método de solicitud (request_password_reset) siempre debe devolver un mensaje genérico, independientemente de si el usuario existe o no en la base de datos (Ej: "Si tu email está registrado, recibirás un link para resetear tu contraseña").

B. Consumo Atómico del Token (Prevención TOCTOU)

• El Problema (Time-Of-Check to Time-Of-Use): Si primero haces un SELECT para verificar que el token es válido, y luego un UPDATE de la contraseña, dos peticiones concurrentes milisegundos aparte podrían evadir la verificación y usar el token dos veces.
• La Solución: Utilizar una operación atómica a nivel de base de datos (UPDATE ... RETURNING). Reclamas e invalidas el token en una sola transacción SQL. Si el UPDATE falla, el token ya estaba consumido o no existía.

C. Rate Limiting de Extremo a Extremo

• Limitar la cantidad de solicitudes no solo en el login, sino también en el endpoint que genera los tokens de reseteo. Esto evita ataques de denegación de servicio (DoS) donde se intente agotar la cuota de la API de Resend o saturar el servidor con emails spam.

Conceptos Relacionados:

• [[Seguridad Web]]
• [[Prevención TOCTOU]]
• [[Rate Limiting]]