Un restablecimiento de contraseña es un login que se salta la contraseña, así que cada control del formulario de acceso debe replicarse allí o sustituirse de forma deliberada. Si la ruta de restablecimiento es más débil que la del login, un atacante la utilizará. La OWASP Forgot Password Cheat Sheet describe esta función como "una fuente habitual de vulnerabilidades", con la enumeración de usuarios como ejemplo más conocido.
Por qué el flujo de restablecimiento es el punto débil
Un login correcto genera una sesión. Según la guía de OWASP sobre gestión de sesiones, el ID de una sesión autenticada equivale, de forma temporal, al método de autenticación más fuerte que haya empleado la aplicación. Un restablecimiento que termina en una sesión, o en una contraseña elegida por el atacante, entrega exactamente lo mismo.
NIST SP 800-63B-4 exige en AAL2 demostrar la posesión y el control de dos factores de autenticación distintos. Si el login pide dos factores, un restablecimiento que solo necesita un token enviado por correo es una vía de factor único para esquivarlo. El extracto en el que nos apoyamos no cubre la recuperación; el documento completo incluye una sección sobre la gestión de eventos del autenticador.
Nuestra regla: en una cuenta con un segundo factor registrado, pida ese factor o un código de recuperación guardado antes de aceptar la nueva contraseña, y no permita nunca que un restablecimiento elimine o sustituya el factor.
El paso de solicitud
Responda de forma idéntica exista o no la cuenta. Basta con "Si esa dirección está registrada, hemos enviado un correo".
El tiempo de respuesta también delata. Un manejador que termina antes para las direcciones desconocidas y envía correo para las conocidas muestra la diferencia, diga lo que diga el mensaje. Ejecute la misma lógica para todas las solicitudes o delegue el envío del correo en un trabajo asíncrono.
Añada rate limiting por cuenta, un CAPTCHA o un control similar. Sin él, un atacante puede lanzar miles de solicitudes de restablecimiento por hora contra una misma cuenta y saturar el correo o los SMS de la víctima. No bloquee ni modifique la cuenta al recibir una solicitud.
El token
OWASP pide cuatro cosas a un token o código:
- que se genere con un algoritmo aleatorio criptográficamente seguro;
- que sea lo bastante largo para resistir la fuerza bruta;
- que se almacene de forma segura;
- que sea de un solo uso y caduque pasado un periodo adecuado.
La hoja no da cifras de longitud ni de duración. El número más cercano en las fuentes está en la guía de sesiones: un CSPRNG con al menos 128 bits de entropía, preferiblemente 160 o más. Está escrito para tokens de sesión; nosotros lo aplicamos a los tokens de restablecimiento. En cuanto a la duración, elija un valor corto, déjelo documentado y pruébelo.
"Almacenado de forma segura" admite una lectura estricta. Si la divulgación de solo lectura del almacén de tokens forma parte de su modelo de amenazas, la guía de sesiones describe una separación entre identificador y verificador secreto. El servidor conserva el identificador público de búsqueda y el hash SHA-256 completo del verificador, y compara los hashes en tiempo constante. El identificador por sí solo nunca debe valer como prueba. Aplicarlo a los tokens de restablecimiento es una sugerencia nuestra.
Entregue el token por un canal independiente, correo electrónico o SMS, y nunca en la respuesta del navegador. Un token en la URL es el diseño más sencillo, pero la guía de sesiones advierte de que los ID en las URL pueden filtrarse a través de enlaces y logs, el historial del navegador, los marcadores, la cabecera Referer y los motores de búsqueda. Mantener contenido de terceros y enlaces externos fuera de la página de restablecimiento solo cierra la fuga por Referer. Para el resto, intercambie el token en la primera solicitud por un estado de corta duración en el servidor, redirija a una URL limpia y mantenga esa primera query string fuera de los logs de acceso.
El paso de restablecimiento
- Pida al usuario que escriba la nueva contraseña dos veces y compruébela con la misma política que en el registro.
- Aplique el hash con el mismo código que utiliza para cualquier otra contraseña.
- Invalide todos los tokens de restablecimiento pendientes de la cuenta cuando cambie la contraseña o la dirección de correo. De lo contrario, un correo antiguo que siga en una bandeja de entrada podría volver a restablecer la cuenta.
- Envíe un correo al usuario para avisarle de que la contraseña ha cambiado. No incluya nunca la contraseña en el mensaje.
- Lleve al usuario al login normal en lugar de iniciarle sesión. El inicio de sesión automático añade código de gestión de sesiones y, con él, la posibilidad de nuevas vulnerabilidades.
- Cierre las sesiones existentes, o al menos ofrezca hacerlo.
Tras un compromiso sospechado, la sesión activa del atacante sobrevive a un cambio de contraseña salvo que usted la cierre. Nosotros haríamos de la invalidación el comportamiento por defecto.
MFA y cuentas comprometidas
Un restablecimiento de contraseña por sí solo puede no devolver el control. El atacante podría seguir teniendo una sesión activa, o haber cambiado la información de recuperación o los métodos de MFA.
OWASP indica que no se debe confiar únicamente en información de recuperación añadida o modificada recientemente. Utilice evidencias independientes establecidas con anterioridad, como códigos de recuperación guardados, en una combinación que cumpla los requisitos de garantía de la cuenta. El restablecimiento del MFA tiene su propia sección en la Multifactor Authentication Cheat Sheet de OWASP, de modo que mantenga ese proceso separado del flujo de contraseña.
La OWASP Authentication Cheat Sheet también trata el cambio de una dirección de correo registrada, algo relevante porque una dirección modificada redirige todos los restablecimientos futuros.
Cómo probar el flujo
| Prueba | Qué aspecto tiene un resultado correcto |
|---|---|
| Dirección real y dirección inexistente | Mismo mensaje y mismo código de estado |
| Lote automatizado de solicitudes por dirección | Las medianas de los tiempos de respuesta coinciden |
| Solicitudes repetidas para una misma cuenta | Se activa el rate limiting o el CAPTCHA |
| Solicitar un restablecimiento y luego iniciar sesión | La cuenta no se bloquea ni se altera |
| Token usado dos veces, o tras caducar | El intento falla |
| Token antiguo tras un cambio de contraseña o de correo | El intento falla |
| Página de restablecimiento con el token en la URL | Sin solicitudes a terceros ni enlaces externos |
| Restablecimiento con una sesión antigua abierta | La sesión antigua se cierra |
| Segundo factor registrado, solo token enviado por correo (nuestra regla) | Restablecimiento rechazado |
| Respuesta final y correo | Sin inicio de sesión automático ni contraseña en el correo |
Para la fila de tiempos, compare medianas y dispersión a lo largo de muchas ejecuciones. Esto forma parte de cualquier test de intrusión de un flujo de autenticación.
Por dónde empezar
- Solicite un restablecimiento para una cuenta existente y otra inexistente, muchas veces con cada una. Compare mensaje, código de estado y tiempo de respuesta.
- Revise el generador de tokens. Confirme que usa un CSPRNG, haga que los tokens sean de un solo uso y fije una duración que pueda expresar en minutos.
- Añada rate limiting por cuenta o un CAPTCHA al endpoint de solicitud, y confirme que una solicitud nunca bloquea ni modifica la cuenta.
- Haga que el restablecimiento cierre las demás sesiones, invalide los tokens pendientes y envíe un correo de notificación sin la contraseña. Compruebe que la página de restablecimiento no carga nada de terceros.
- Tome una cuenta de prueba con MFA registrado e intente restablecerla usando solo el token enviado por correo. Confirme que el restablecimiento se rechaza.
- Compruebe quién puede restablecer o eliminar un segundo factor, qué evidencias debe presentar y si la recuperación trata como no fiables los datos modificados recientemente.
