Cómo evitar el abuso del restablecimiento de contraseña en su sitio web (2026)

Ilustración sobre la prevención del uso indebido del restablecimiento de contraseñas, que muestra amenazas como los ataques automatizados, la enumeración de usuarios, la inundación de correos electrónicos y el relleno de credenciales junto con protecciones como la limitación de velocidad, la verificación CAPTCHA, la protección de la existencia de cuentas y las alertas de supervisión. — captcha.eu

La mayoría de los equipos protegen su página de inicio de sesión cuidadosamente y dejan el flujo de restablecimiento de contraseña casi abierto. Los atacantes lo saben. Utilizan el flujo de restablecimiento para enumerar las cuentas válidas, inundar las bandejas de entrada con correos electrónicos automatizados, robar tokens mediante la generación de enlaces débiles y eludir las protecciones de inicio de sesión que usted dedicó tiempo a reforzar. Esta guía explica cada patrón de abuso de restablecimiento y los pasos prácticos que detienen cada uno de ellos.

Tiempo estimado de lectura: 13 minutos

Pruebe CAPTCHA.eu gratis - sin tarjeta de crédito

Ver todas las integraciones

De un vistazo

Por qué se abusa de los flujos de restablecimiento

El flujo de restablecimiento evita por completo la página de inicio de sesión. Si es más débil que su inicio de sesión, los atacantes lo utilizan como el camino más fácil para acceder a la cuenta

Cuatro modelos de maltrato que conviene conocer

Enumeración de cuentas, inundación de restablecimientos, robo de tokens y diseño de recuperación débil. Cada uno necesita una defensa diferente, y ninguno de ellos se resuelve sólo con la protección de inicio de sesión

La solución más rápida

Devuelve la misma respuesta tanto si existe una cuenta como si no. Este único cambio elimina la enumeración de cuentas con un coste de ingeniería cero.

Contenido de esta guía

Por qué los flujos de restablecimiento de contraseñas son un objetivo
Los cuatro patrones de abuso del restablecimiento de contraseñas
Siete defensas que funcionan
Dónde encaja CAPTCHA en la protección de restablecimiento de contraseñas
Abuso del restablecimiento de contraseñas y obligaciones GDPR
Lista de control de la aplicación
Preguntas frecuentes

Por qué los flujos de restablecimiento de contraseñas son un objetivo

El flujo de restablecimiento de contraseña es la puerta trasera de tu sistema de autenticación. Su trabajo es permitir a los usuarios volver a entrar sin su contraseña, lo que significa que debe eludir la comprobación normal de credenciales por diseño. Eso lo hace estructuralmente más débil que el inicio de sesión, y los atacantes explotan esa brecha directamente.

Tres cosas hacen que los flujos de reinicio sean objetivos atractivos. En primer lugar, la mayoría de los equipos añaden una sólida protección contra bots al inicio de sesión, pero descuidan por completo el punto final de restablecimiento. En segundo lugar, los flujos de restablecimiento revelan información útil a los atacantes: si existe una cuenta, qué direcciones de correo electrónico están registradas y con qué rapidez caducan los tokens de restablecimiento. En tercer lugar, los formularios de restablecimiento son públicos y fáciles de automatizar: un bot puede lanzar miles de solicitudes de restablecimiento por hora contra un formulario sin limitación de velocidad ni CAPTCHA.

El resultado es que incluso los equipos que han endurecido el inicio de sesión, añadido MFA e implementado la limitación de velocidad a menudo dejan el restablecimiento de contraseñas como una entrada lateral desprotegida. OWASP's Forgot Password Cheat Sheet enumera las vulnerabilidades de flujo de restablecimiento entre las debilidades de autenticación más comúnmente explotadas en aplicaciones de producción. El punto más débil de su sistema de autenticación es el único que importa a un atacante decidido, y si ese punto es su formulario de restablecimiento, toda la protección de su página de inicio de sesión no cuenta para nada.

Los cuatro patrones de abuso del restablecimiento de contraseñas

El abuso del restablecimiento de contraseñas no es un único tipo de ataque. Es una categoría de cuatro patrones distintos, cada uno con diferentes objetivos y diferentes defensas requeridas.

PATRÓN DE ABUSO	QUÉ HACEN LOS ATACANTES	LO QUE GANAN
Enumeración de cuentas	Envíe solicitudes de restablecimiento para muchas direcciones de correo electrónico y observe si las respuestas difieren según se trate de cuentas existentes o inexistentes.	Una lista validada de direcciones de correo electrónico de cuentas reales para su uso en phishing, relleno de credenciales o ataques selectivos.
Reiniciar inundación	Enviar automáticamente un gran número de correos electrónicos de restablecimiento a una o varias cuentas	Sobrecarga de la bandeja de entrada que entierra correos de phishing, acoso a los usuarios o degradación de la reputación de la infraestructura de correo.
Robo de tokens y fuerza bruta	Interceptar enlaces restablecidos a través de cabeceras de referencia, URL archivadas o el historial del navegador; o tokens cortos/predecibles de fuerza bruta.	Token de restablecimiento válido que les permite establecer una nueva contraseña y hacerse cargo de la cuenta sin conocer la original.
Diseño de recuperación deficiente	Explotar métodos de recuperación inseguros: tokens reutilizables, enlaces que no caducan, preguntas de seguridad con respuestas adivinables o intercambio de SIM para interceptar códigos SMS.	Acceso a la cuenta a través de la ruta de recuperación sin necesidad de interrumpir el flujo de inicio de sesión.

Estos cuatro patrones suelen aparecer juntos en una misma campaña de ataque. Un atacante puede comenzar con la enumeración para identificar cuentas reales y, a continuación, utilizar la inundación de restablecimiento para crear confusión mientras ejecuta un robo de token o un intercambio de SIM contra un objetivo específico de alto valor. Para defenderse de los cuatro tipos de ataques se necesitan controles por capas, no una única solución.

Siete defensas que funcionan

Respuestas coherentes para cuentas existentes y no existentes
Este es el cambio más importante que puedes hacer, y no cuesta casi nada implementarlo. Cuando un usuario envíe una solicitud de restablecimiento de una dirección de correo electrónico, devuelva exactamente el mismo mensaje, el mismo código de estado HTTP y el mismo tiempo de respuesta tanto si la cuenta existe como si no. Un mensaje como “Si existe una cuenta con esa dirección, recibirá un correo electrónico de restablecimiento” cierra completamente la enumeración de cuentas. El error común es devolver “Le enviamos un correo electrónico de restablecimiento” para las cuentas reales y “No se encontró ninguna cuenta” para las inexistentes. OWASP's Forgot Password Cheat Sheet señala específicamente este patrón como una de las vulnerabilidades de enumeración más frecuentes en las aplicaciones de producción. Corrige el texto de respuesta, pero también comprueba el tiempo de respuesta: si tu aplicación consulta la base de datos antes de devolver una respuesta, la diferencia de tiempo entre una cuenta real y una fallida puede filtrar información. Utiliza un procesamiento asíncrono o un retraso artificial para que el tiempo sea coherente.
Añadir CAPTCHA al formulario de solicitud de restablecimiento
CAPTCHA en el formulario de restablecimiento detiene dos patrones de abuso a la vez: la inundación de restablecimiento y la enumeración de cuentas a escala. Un atacante que comprueba miles de direcciones de correo electrónico en busca de cuentas válidas necesita automatizar esas solicitudes. Un CAPTCHA de prueba de trabajo fuerza un cálculo criptográfico para cada envío, lo que hace que la automatización a gran escala sea económicamente inviable sin afectar a los usuarios legítimos que envían una solicitud cada vez. Para los sitios web europeos, la elección del CAPTCHA importa aquí más que en casi cualquier otro lugar. El formulario de restablecimiento es una página crítica para la seguridad en la que los usuarios ya se encuentran en un estado vulnerable: han perdido el acceso a su cuenta. Añadir un CAPTCHA de comportamiento basado en cookies introduce preguntas sobre el consentimiento de privacidad en el momento más inoportuno. Un CAPTCHA de prueba sin cookies se integra sin necesidad de avisos de consentimiento adicionales en las páginas de recuperación. Para una explicación completa de cómo funciona, consulte nuestra guía sobre qué es un CAPTCHA invisible.

CAPTCHA.eu detiene la inundación de restablecimientos y la enumeración a escala con verificación de prueba de trabajo invisible. Sin cookies, alojado en Austria, certificado WCAG 2.2 AA por TÜV Austria.

Iniciar prueba gratuita

Ver todas las integraciones

Aplicar limitación de tarifa por cuenta y por IP
La limitación de velocidad en el punto final de restablecimiento limita el volumen de abusos incluso cuando ya se ha implementado CAPTCHA. Aplique límites a dos niveles: por dirección IP y por cuenta. La limitación a nivel de IP frena a un atacante que utilice un número reducido de direcciones. La limitación a nivel de cuenta garantiza que incluso un ataque distribuido no pueda inundar una sola bandeja de entrada repetidamente. Un umbral inicial razonable es de tres a cinco solicitudes de restablecimiento por cuenta y hora. A partir de ese límite, rechace las nuevas solicitudes en silencio: devuelva la misma respuesta coherente sin enviar un nuevo correo electrónico. No le diga al usuario que ha alcanzado un límite de velocidad, ya que esto filtra información sobre su lógica de limitación de velocidad. Aplique también límites al punto final de validación de tokens: un atacante que intente forzar un token de restablecimiento necesita enviar muchos intentos de token, y limitar la tasa de ese punto final elimina por completo la superficie de ataque para tokens cortos.
Utilizar fichas criptográficamente sólidas, efímeras y de un solo uso.
Los tokens de restablecimiento son las claves de las cuentas de sus usuarios. Genérelos con un generador de números aleatorios criptográficamente seguro, no con una marca de tiempo, no con un ID secuencial, no con un hash de entradas predecibles. NIST SP 800-63B recomienda al menos 20 bytes de entropía para los secretos de restablecimiento, lo que se traduce en un token de al menos 40 caracteres hexadecimales o una codificación base64 equivalente. Establece una caducidad corta: una hora es generoso para la mayoría de las aplicaciones; de 15 a 30 minutos es apropiado para contextos de mayor seguridad. Expire el token inmediatamente después de su uso: un token que sigue siendo válido después de restablecer la contraseña es una puerta trasera persistente. Expire también todos los demás tokens activos para esa cuenta cuando se solicite un nuevo restablecimiento: si un atacante activa un nuevo restablecimiento después de que el usuario ya haya recibido uno, el token antiguo ya no debería funcionar.
Evitar la fuga de tokens mediante cabeceras de referencia y almacenamiento en caché
Los tokens de restablecimiento entregados en URL se enfrentan a un riesgo específico: el token puede filtrarse a través del encabezado HTTP Referrer si la página de restablecimiento contiene recursos externos (scripts de análisis, fuentes, activos CDN o imágenes de terceros). Cuando un usuario hace clic en un enlace de su página de restablecimiento, el navegador puede enviar la URL completa (incluido el token) como Referrer a servidores externos. Para evitarlo, establezca Referrer-Policy: no-referrer en la página de confirmación del restablecimiento. Defina también las cabeceras de control de caché adecuadas para evitar que las URL de restablecimiento se almacenen en el historial del navegador o en las cachés de proxy. Indique a la aplicación que no registre valores de token de restablecimiento en registros de acceso o sistemas de seguimiento de errores, ya que son una fuente común de exposición involuntaria de tokens en entornos de producción.
Sustituir las preguntas de seguridad por canales secundarios verificados
Las preguntas de seguridad no son un método de recuperación seguro. Las respuestas a las preguntas de seguridad más comunes (nombre de soltera de la madre, mascota de la infancia, primer colegio) suelen estar disponibles públicamente a través de las redes sociales, intermediarios de datos o investigaciones específicas. Proporcionan la apariencia de verificación sin la sustancia. Sustituya las preguntas de seguridad por canales secundarios verificados: correo electrónico a una dirección confirmada en el registro o códigos TOTP basados en aplicaciones. Si la recuperación basada en SMS es inevitable, comprenda que el intercambio de SIM la hace vulnerable para las cuentas de alto valor. Para las cuentas en las que hay mucho en juego (acceso de administrador, credenciales de pago, registros sanitarios), exija un segundo canal verificado en lugar de una única vía de recuperación.
Notificar a los usuarios y supervisar los patrones de reinicio anómalos
Envía a los usuarios una notificación cuando se solicite un restablecimiento, no sólo cuando se haya completado. Un mensaje como “Se ha solicitado un restablecimiento de contraseña para su cuenta. Si no es usted, puede ignorar este correo electrónico: su contraseña no ha cambiado” da a los usuarios la oportunidad de reaccionar antes de que un atacante utilice un token robado. Desde el punto de vista de la supervisión, un aumento repentino de las solicitudes de restablecimiento es una señal temprana de una campaña de enumeración o inundación. Establezca alertas para volúmenes de restablecimiento inusuales por IP, por cuenta o en toda la aplicación. Correlacione los picos de restablecimiento con los patrones de fallo de inicio de sesión: los atacantes suelen probar las cuentas enumeradas en la página de inicio de sesión antes de cambiar al flujo de restablecimiento cuando se encuentran con la limitación de velocidad o el CAPTCHA.

La postura de seguridad mínima viable

Si sólo implementas tres cosas: respuestas coherentes (Defensa 1), CAPTCHA en el formulario de restablecimiento (Defensa 2) y tokens de un solo uso de corta duración (Defensa 4), cierras las vulnerabilidades de restablecimiento más comúnmente explotadas. Añade las demás progresivamente en función de la sensibilidad de las cuentas que protejas.

Dónde encaja CAPTCHA en la protección de restablecimiento de contraseñas

CAPTCHA en el formulario de restablecimiento de contraseña cumple una función específica y limitada: detiene el abuso automatizado del punto final de restablecimiento. Evita que los bots comprueben miles de direcciones de correo electrónico en busca de cuentas válidas e impide la inundación automatizada de restablecimiento contra usuarios específicos. No soluciona la generación de tokens débiles, no evita la fuga de tokens a través de las cabeceras de referencia y no sustituye el diseño de respuestas coherentes.

Este posicionamiento es importante porque algunos equipos confían demasiado en CAPTCHA (utilizándolo como único control) o lo infrautilizan (saltándoselo porque “los usuarios no deberían tener que resolver un rompecabezas para restablecer su contraseña”). En ambos casos, no se trata de eso. El CAPTCHA invisible de prueba de trabajo no añade ninguna fricción visible para los usuarios legítimos que envían una solicitud de restablecimiento. Sólo aumenta el coste para los robots que envían miles. Ese es precisamente el lugar que ocupa CAPTCHA en la pila de defensa.

Para el flujo de restablecimiento de WordPress en concreto, nuestro Guía CAPTCHA de WordPress cubre la integración a nivel de wp-login.php. Para Keycloak, el flujo de restablecimiento de credenciales requiere un fragmento FTL separado de los flujos de inicio de sesión y registro: nuestro Guía de integración de Keycloak cubre los tres flujos con pasos de configuración específicos.

Un ataque exitoso de restablecimiento de contraseña que resulte en el acceso no autorizado a una cuenta constituye una violación de datos personales bajo el GDPR. Si la cuenta comprometida contenía datos personales (como casi todas las cuentas de usuario), se enfrenta a las obligaciones de evaluación y notificación del artículo 33.

También hay un ángulo GDPR específico en el propio formulario de restablecimiento. Los servicios CAPTCHA tradicionales que establecen cookies en las páginas de recuperación crean un requisito de consentimiento de ePrivacy en un momento incómodo: un usuario que ha perdido el acceso a su cuenta ahora debe navegar por un banner de consentimiento de cookies antes de recuperarla. Un CAPTCHA de prueba de trabajo sin cookies elimina este problema estructuralmente. No se necesita ningún mecanismo de consentimiento para la capa CAPTCHA en sí, lo que supone una simplificación significativa del cumplimiento para los DPO que gestionan la carga de documentación de los flujos de autenticación.

El ángulo del artículo 32

El artículo 32 del GDPR exige medidas técnicas de seguridad adecuadas. Para cualquier sitio web que almacene datos personales detrás de las cuentas de usuario, no proteger el flujo de restablecimiento es cada vez más difícil de defender en una revisión de la autoridad de supervisión. La inundación de restablecimientos, la enumeración y el robo de tokens son patrones de ataque bien documentados con contramedidas bien conocidas. Aplicarlas forma parte de una postura razonable conforme al artículo 32.

Lista de control de la aplicación

Utilice esta lista de comprobación para auditar su actual flujo de restablecimiento. Los elementos están ordenados por impacto por esfuerzo de implementación: los elementos principales ofrecen la mayor protección por el menor trabajo.

Respuestas coherentes: Compruebe que su formulario de restablecimiento devuelve el mismo mensaje, código de estado y tiempo de respuesta para las cuentas existentes y las no existentes.
CAPTCHA en el formulario de reinicio: Añadir CAPTCHA invisible de prueba de trabajo al formulario de solicitud de restablecimiento. Para WordPress: consulte la guía de WordPress. Para Keycloak: ver la guía Keycloak.
Limitación de velocidad por cuenta y por IP: Aplicar límites a ambos niveles. Rechazar silenciosamente después del umbral: no revelar que existe el límite.
Fichas criptográficamente fuertes: Confirme que su generador de tokens utiliza un CSPRNG con al menos 20 bytes de entropía. Rechaza ID secuenciales, marcas de tiempo y patrones de hash de correo electrónico.
Caducidad de la ficha: Las fichas caducan una hora después de su emisión. Las fichas caducan inmediatamente después de su uso. Las nuevas solicitudes de restablecimiento invalidan todos los tokens anteriores de esa cuenta.
Cabecera Referrer-Policy: Establecer Política de referencia: no-referrer en las páginas de confirmación de reinicio. Revise todos los recursos externos cargados en estas páginas.
Sin preguntas de seguridad: Sustituir por verificación basada en correo electrónico o TOTP. Audite cualquier flujo de preguntas de seguridad heredado que siga activo en su aplicación.
Restablecer notificaciones de solicitud: Envíe a los usuarios un correo electrónico cuando se active un restablecimiento, no sólo cuando se complete.
Supervisión y alerta: Establezca alertas para picos de volumen de reinicio por IP y por cuenta. Correlacione con patrones de fallo de inicio de sesión.
HTTPS en todas partes en los flujos de restablecimiento: Asegúrese de que todas las páginas de restablecimiento y los puntos finales de envío de tokens utilizan HTTPS con TLS actual. Rechace los tokens de restablecimiento enviados a través de HTTP.

Preguntas frecuentes

¿Qué es el abuso del restablecimiento de contraseña?

El abuso del restablecimiento de contraseñas es el uso indebido de un flujo de recuperación de cuentas para obtener acceso no autorizado, enumerar cuentas válidas, inundar bandejas de entrada o robar tokens de recuperación. Es distinto del envenenamiento de restablecimiento de contraseña, que es una vulnerabilidad técnica específica en la que un atacante manipula cómo se genera el enlace de restablecimiento. El abuso del restablecimiento es una categoría más amplia que incluye cuatro patrones de ataque distintos: enumeración, inundación, robo de tokens y diseño de recuperación débil.

¿Cuál es la diferencia entre el abuso del restablecimiento de contraseñas y el envenenamiento del restablecimiento de contraseñas?

El envenenamiento de restablecimiento de contraseña es una técnica específica dentro de la categoría más amplia de abuso de restablecimiento. El envenenamiento se produce cuando un atacante manipula el encabezado HTTP Host para redirigir un enlace de restablecimiento a un dominio controlado por el atacante. El abuso de restablecimiento abarca un conjunto más amplio de patrones: enumeración de cuentas a través de diferencias de respuesta, inundación de restablecimiento para saturar las bandejas de entrada, forzamiento de token y explotación de métodos de recuperación débiles como preguntas de seguridad o interceptación de SMS.

¿Impide CAPTCHA el abuso en el restablecimiento de contraseñas?

CAPTCHA detiene los patrones de abuso automatizados: inundación de restablecimiento y enumeración de cuentas a gran escala. No soluciona la generación de tokens débiles, no evita la fuga de tokens a través de las cabeceras de referencia y no sustituye el diseño de respuestas coherentes. Utilice CAPTCHA como una capa en una pila de seguridad de restablecimiento más amplia, no como el único control.

¿Cómo enumeran los atacantes las cuentas a través del formulario de restablecimiento?

Si su formulario de restablecimiento devuelve respuestas diferentes para cuentas existentes y no existentes (texto de mensaje diferente, códigos de estado HTTP diferentes o tiempos de respuesta considerablemente diferentes), un atacante puede enviar solicitudes de restablecimiento para una lista de direcciones de correo electrónico y observar cuáles devuelven la respuesta “cuenta encontrada”. Esto revela su base de usuarios registrados sin necesidad de descifrar ninguna contraseña. La solución es devolver siempre la misma respuesta, independientemente de si la cuenta existe o no.

¿Cuánto tiempo debe ser válida una ficha de restablecimiento?

Una hora es un máximo razonable para la mayoría de las aplicaciones. Para contextos de mayor seguridad (cuentas financieras, asistencia sanitaria, acceso administrativo), de 15 a 30 minutos es más apropiado. El token debe caducar inmediatamente después de su uso, y todos los tokens anteriores de una cuenta deben ser invalidados cuando se solicite un nuevo restablecimiento. Los tokens que siguen siendo válidos después de su uso son una puerta trasera persistente.

¿Es el flujo de restablecimiento de contraseña una preocupación GDPR?

Sí, en dos sentidos. En primer lugar, un ataque exitoso que conduce a un acceso no autorizado a la cuenta es una violación de datos personales en virtud del GDPR, lo que desencadena la evaluación del artículo 33 y las posibles obligaciones de notificación. En segundo lugar, los CAPTCHA basados en cookies en las páginas de recuperación crean una pregunta de consentimiento de ePrivacy en un momento difícil para los usuarios. Un CAPTCHA sin cookies elimina por completo ese requisito de consentimiento del flujo de recuperación.

Ilustración de un sistema CAPTCHA invisible que muestra un formulario de un sitio web, un fantasma que simboliza la verificación oculta y un tablero con la etiqueta “Prueba de trabajo” que confirma “Usuario verificado” mediante comprobaciones automáticas de antecedentes.

Fuentes primarias

Hoja de trucos de OWASP para el olvido de contraseñas: respuestas coherentes, diseño seguro de los tokens y recomendaciones para limitar la velocidad
Hoja de trucos de autenticación OWASP: prácticas de reautenticación y autenticación segura
Academia de Seguridad Web PortSwigger: Envenenamiento de restablecimiento de contraseña: detalles técnicos sobre la explotación del encabezamiento del host en los flujos de restablecimiento
NIST SP 800-63B: orientaciones sobre autenticadores secretos memorizados y requisitos de entropía de restablecimiento de secretos
Guía de Pruebas OWASP: Funciones de restablecimiento de contraseñas débiles
CAPTCHA.eu: ¿Qué es el envenenamiento por restablecimiento de contraseña?: definición y distinción entre intoxicación y abuso de reajuste más amplio
CAPTCHA.eu: Cómo evitar los ataques de apropiación de cuentas: contexto más amplio de la seguridad de la autenticidad, incluidos los flujos de restablecimiento

Cómo evitar el abuso del restablecimiento de contraseñas en su sitio web (2026)

De un vistazo

Por qué se abusa de los flujos de restablecimiento