Guías de seguridad
Fallos de diseño en el restablecimiento de contraseña: 5 formas de perder una cuenta pese a un login fuerte, y cómo corregirlas
Si «¿Olvidaste tu contraseña?» es débil, ni una contraseña larga ni el MFA evitan que tomen la cuenta. Las 5 formas en que falla y lo que exige OWASP.
«¿Olvidaste tu contraseña?» lleva a un mecanismo para que alguien que no conoce la contraseña pueda fijar una nueva. Eso lo convierte en una vía de autenticación, y normalmente en la más débil que tiene el servicio.
Por qué reforzar solo el login no lo evita
Vía habitual: inicio de sesión
Contraseñas largas · multifactor · límite de intentos · detección de fuerza bruta
─────── la misma cuenta ───────
Otra vía: restablecimiento de contraseña
Funciona si llega el correo · a menudo sin segundo factor · la fuerza del token no se ve
El restablecimiento se construye como una comodidad para los usuarios, y por eso a menudo no se diseña ni se revisa con el mismo rigor que la autenticación. Sin embargo, en la práctica entrega el control de una cuenta a alguien que no conoce la contraseña. Pertenece a la misma categoría que el propio login.
Esto encaja con lo que vimos al clasificar los incidentes japoneses de 2026 según cómo entraron los atacantes (en inglés): entrar con credenciales válidas es más frecuente que explotar una vulnerabilidad. Un flujo de restablecimiento es el punto en el que un servicio emite esas credenciales mediante su propio procedimiento oficial.
Las cinco formas que adopta
- 1. Tokens adivinables
- Valores secuenciales, marcas de tiempo, cadenas cortas o aleatoriedad no criptográfica. El restablecimiento de otra persona se puede completar adivinando o por fuerza bruta
- 2. Tokens que nunca mueren
- Sin caducidad, válidos tras usarse, reutilizables. Un enlace emitido una vez sigue funcionando indefinidamente
- 3. Enlaces que siguen vivos en un buzón
- Quien lee el buzón puede leer el enlace de restablecimiento. Reglas de reenvío, cuentas compartidas, el buzón de un compañero que ya se fue: el correo lo ven más ojos de los que imaginas
- 4. Destinos fijados desde fuera
- Si construyes la URL de restablecimiento a partir de la cabecera
Hostde la petición, un valor externo puede acabar como enlace en tu correo (inyección de cabecera Host) - 5. Respuestas que delatan la cuenta
- Un amable «no registrado», o una diferencia en el tiempo de respuesta, convierte el formulario en una forma de comprobar desde fuera quién tiene cuenta (enumeración de usuarios)
CWE-640, «Weak Password Recovery Mechanism for Forgotten Password» (mecanismo débil de recuperación de contraseña olvidada), es el nombre de esta clase. Su definición: el producto contiene un mecanismo para que los usuarios recuperen o cambien su contraseña sin conocer la original, pero ese mecanismo es débil. Fíjate en lo que dice: el problema no es tener la función, sino que la función no sea tan fuerte como la autenticación que puede sustituir.
No uses las preguntas de seguridad como única vía
La postura de OWASP sobre las preguntas de seguridad es que no deben usarse como único mecanismo para restablecer contraseñas, porque sus respuestas suelen ser fáciles de adivinar o de conseguir para un atacante, aunque señala que pueden añadir una capa extra combinadas con otros métodos. El apellido de soltera de tu madre no es un secreto en la era de los perfiles sociales y los registros públicos.
Lo que exige la guía y lo que deja en tus manos
Aquí es donde las implementaciones dudan. Mantén las dos cosas separadas.
Lo que OWASP establece de forma explícita
・Generar los tokens con un generador de números aleatorios criptográficamente seguro
・Que sean lo bastante largos para resistir la fuerza bruta
・Invalidarlos tras usarse
・Devolver un mensaje idéntico para cuentas que existen y que no existen
・Mantener también tiempos de respuesta uniformes, para evitar la enumeración
・Usar límite de peticiones, CAPTCHA o controles similares contra envíos automatizados
・Invalidar las sesiones existentes automáticamente, o preguntar al usuario si quiere hacerlo
・Avisar por correo al usuario de que se restableció su contraseña, y no incluir la contraseña
・No depender de la cabecera Host al construir las URL de restablecimiento (fíjala en el código o valídala contra una lista de dominios de confianza)
・Asegurar que la URL usa HTTPS
Cifras que la guía no fija (te toca decidirlas)
・La longitud real del token: solo se dice «lo bastante largo»
・El plazo de caducidad: se exige invalidar al usarse; el límite de tiempo no lleva cifra
No leas la falta de una cifra como «esto no hay que decidirlo». Hay que decidirlo con un motivo, y dejarlo por escrito.
Nuestros valores prácticos por defecto: al menos 128 bits de aleatoriedad en codificación segura para URL; caducidad de unas decenas de minutos; invalidación al usarse; e invalidación de los tokens anteriores cada vez que se emite uno nuevo para la misma cuenta. Las cifras importan menos que las tres propiedades: imposible de adivinar, no reutilizable, no eterno.
Orden de implementación
Haz que el token sea imposible de adivinar (primera prioridad)
Genéralo con una fuente aleatoria criptográfica y codifícalo de forma segura para URL. No uses una función aleatoria de uso general: «parece aleatorio» y «no se puede predecir» son propiedades distintas. Guarda un hash del token en lugar del token, para que una base de datos legible no entregue al instante tokens utilizables (el mismo razonamiento que en almacenamiento de contraseñas, hash y sal).
Dale una vida limitada y que solo se use una vez
Invalídalo al usarse y que caduque también por tiempo. Cuando se emite un token nuevo para la misma cuenta, invalida también los anteriores: si lo olvidas, vuelves a la forma 2.
Nunca construyas la URL con datos externos
Genera el enlace de restablecimiento a partir de la configuración, o valídalo contra una lista de dominios de confianza. No pases una cabecera de la petición al correo. OWASP lo menciona de forma directa.
Uniformiza las respuestas y limita las peticiones
Devuelve el mismo texto y en el mismo tiempo en ambos casos, y envía el correo solo cuando la cuenta existe de verdad. Añade un límite de peticiones por cuenta o un CAPTCHA contra envíos automatizados. Los usuarios no salen perjudicados; desde fuera, los dos casos no se distinguen.
Cierra el proceso al completarse
Al completar un restablecimiento, invalida las sesiones existentes (si la cuenta ya estaba tomada, es la única forma de echar al atacante) y envía un aviso de que se restableció la contraseña (sin incluirla). Donde puedas, exige también un segundo factor en la vía de restablecimiento, para que no se convierta en la forma de esquivar la autenticación multifactor.
De lo que depende realmente el restablecimiento es del buzón
Aunque hagas todo lo anterior, la seguridad del restablecimiento sigue dependiendo de que solo el titular pueda recibir el correo. Si la cuenta de correo está comprometida, un restablecimiento bien construido entrega la cuenta al atacante con más fiabilidad que uno descuidado. Por eso la prioridad del lado del usuario acaba en el mismo sitio: da a la cuenta de correo tu protección más fuerte, con una contraseña fuerte y única y autenticación multifactor, idealmente una passkey. También es la vía por la que una brecha en un proveedor llega hasta ti (qué hacer cuando tu proveedor de hosting sufre una brecha).
Cómo se ve desde el lado del usuario
- Un correo de restablecimiento que no pediste es un aviso de que alguien lo intentó. No sigas el enlace: entra tú mismo en el servicio y compruébalo (el phishing llega con exactamente el mismo aspecto).
- Que te cierren la sesión en otros dispositivos tras un restablecimiento es señal de una implementación correcta. Un servicio que deja vivas las demás sesiones tras un restablecimiento no te da forma de echar a un intruso.
- Si no te piden un segundo factor durante el restablecimiento, puede que en ese servicio la autenticación multifactor se pueda esquivar por esa vía. Vale la pena probarlo una vez en las cuentas importantes.
- Acabar con la reutilización de contraseñas es mejor dejárselo a un gestor de contraseñas.
La opinión de este sitio: constrúyelo como autenticación, no como comodidad
Los flujos de restablecimiento se vuelven débiles no porque sean técnicamente difíciles, sino porque se archivan bajo el epígrafe equivocado. El inicio de sesión lo construye con cuidado el equipo de autenticación; «¿Olvidaste tu contraseña?» se construye a la ligera como una vía de soporte. Esa diferencia de trato es la debilidad. Nuestra postura es sencilla: cualquier operación que entregue el control de una cuenta es una función de autenticación (el restablecimiento, el cambio de dirección de correo, volver a registrar un segundo factor, la recuperación manual por un agente de soporte). La fuerza la marca la vía más débil, no la más fuerte. Escribe todas las vías que llegan a una cuenta en tu propio servicio; normalmente hay más de las que imaginabas.
Fuentes (primarias)
- OWASP Cheat Sheet Series, «Forgot Password Cheat Sheet» — cheatsheetseries.owasp.org (todos los requisitos listados arriba como «establecidos de forma explícita» proceden de este documento; no fija una longitud de token ni un plazo de caducidad)
- MITRE, CWE-640 «Weak Password Recovery Mechanism for Forgotten Password» — cwe.mitre.org
Para seguir leyendo
- Defensa: cómo elegir y usar un gestor de contraseñas / almacenamiento de contraseñas, hash y sal
- Términos: qué es la autenticación de dos factores / qué es una passkey / qué es el phishing
- Control de abusos: límite de peticiones y control de abusos (dónde va el límite de peticiones de la vía de restablecimiento)
- Tendencia: en 2026, los atacantes llegaron con credenciales más a menudo que con exploits (en inglés)
FAQ
QSi tengo activada la autenticación multifactor, ¿sigue importando un restablecimiento débil?
Sí. Muchas implementaciones no piden un segundo factor en el restablecimiento, y donde es así, el restablecimiento es una forma de recuperar la cuenta esquivando el segundo factor. Lo que proteges no es la fuerza de la pantalla de login, sino la de todas las vías que llegan a la cuenta. Invalida las sesiones existentes cuando se completa un restablecimiento y, donde puedas, exige también el segundo factor en esa vía.
Q¿Qué longitud debe tener un token de restablecimiento y cuánto debe durar?
La Forgot Password Cheat Sheet de OWASP dice que los tokens deben generarse con un generador de números aleatorios criptográficamente seguro, ser lo bastante largos para resistir la fuerza bruta e invalidarse tras usarse; no fija un número de caracteres ni de minutos. Eso te toca decidirlo a ti. Nuestros valores prácticos por defecto: al menos 128 bits de aleatoriedad en una codificación segura para URL, una caducidad de unas decenas de minutos, invalidación al usarse e invalidación de los tokens anteriores cada vez que se emite uno nuevo para la misma cuenta. Las cifras importan menos que las tres propiedades: imposible de adivinar, no reutilizable, no eterno.
Q¿No es útil mostrar «esa dirección de correo no está registrada»?
Útil para tus usuarios, y una forma gratuita de que un atacante compruebe qué direcciones tienen cuenta contigo. OWASP pide un mensaje idéntico para cuentas que existen y que no existen, y que las respuestas tarden lo mismo. Muestra lo mismo en ambos casos y envía el correo solo cuando la cuenta existe de verdad: los usuarios no salen perjudicados y desde fuera no se nota la diferencia.
Q¿Qué puedo hacer como usuario?
Un correo de restablecimiento que no pediste es un aviso de que alguien lo intentó con tu cuenta. No sigas el enlace: entra tú mismo en el servicio y comprueba que la contraseña no se reutiliza en ningún otro sitio y que la autenticación multifactor está activa. Y recuerda de qué depende realmente el restablecimiento: de tu buzón. Si alguien puede leer tu correo, puede restablecer las contraseñas de muchas de tus cuentas una tras otra. Dale a la cuenta de correo tu protección más fuerte.