Evitar la enumeración de cuentas en registro, inicio de sesión y restablecimiento

Cómo se ve la enumeración de cuentas en la vida real

La enumeración de cuentas ocurre cuando alguien puede saber si un correo, nombre de usuario o número de teléfono está registrado solo por cómo responde tu app. No necesitan iniciar sesión. Solo deben probar muchas conjeturas y observar diferencias en mensajes, códigos de estado, tiempos o efectos secundarios.

Registro, inicio de sesión y restablecimiento de contraseña son objetivos comunes porque están expuestos públicamente y suelen comportarse de forma distinta cuando una cuenta existe. Eso facilita filtrar pistas por accidente.

Un ejemplo simple: un formulario de restablecimiento de contraseña dice:

• “Te hemos enviado un enlace de restablecimiento” cuando el correo existe
• “No se encontró la cuenta” cuando no existe

Un atacante puede subir una lista de 50,000 correos y aprender rápido quién usa tu producto. Esa lista puede venderse, usarse para acoso o para phishing dirigido (“Sé que tienes una cuenta, haz clic aquí”). También mejora la eficiencia del credential stuffing porque los atacantes se concentran solo en correos confirmados.

La enumeración es también un problema de privacidad. Confirmar que alguien tiene una cuenta puede ser sensible en productos de salud, finanzas, trabajo o educación.

El objetivo es simple: hacer que el resultado visible para el usuario sea indistinguible tanto si la cuenta existe como si no, mientras mantienes buena visibilidad interna. Los usuarios deberían ver el mismo mensaje, el mismo patrón de códigos de estado y un tiempo de respuesta similar. Internamente, sigues registrando la verdad en logs y métricas.

Las señales que usan los atacantes para adivinar si existe una cuenta

Los atacantes no necesitan tu base de datos. Solo necesitan pequeñas diferencias en lo que tu app devuelve cuando alguien escribe un correo o teléfono.

Las señales más obvias están en la propia respuesta: un 404 por “usuario no encontrado” vs 200 por “reset enviado”, o JSON como error: \"no_such_user\". Aunque el texto parezca amable, distintos códigos de estado, códigos de error o formatos de respuesta facilitan la automatización.

El comportamiento de la UI puede ser igual de revelador. Si la web dice “No se encontró la cuenta” en el inicio, pero la app móvil siempre dice “Revisa tu correo”, los atacantes usarán la opción más fácil. Lo mismo ocurre cuando las páginas HTML difieren de las APIs JSON: una puede filtrar una pista en el cuerpo, en una cabecera o en un redirect.

Señales comunes que miden los atacantes:

• Códigos de estado y códigos de error (200 vs 404, USER_NOT_FOUND vs INVALID_PASSWORD)
• Texto de mensajes y estados de UI (banners distintos, campos resaltados, botones deshabilitados)
• Tiempos de respuesta (fallo rápido para usuarios desconocidos, ruta más lenta para usuarios reales)
• Avisos secundarios (CAPTCHA que aparece solo tras un “correo real”)
• Efectos fuera de banda (correo/SMS enviados solo para cuentas existentes)

Las diferencias de tiempo importan más de lo que la mayoría de equipos esperan. Si una petición de restablecimiento responde en 40 ms para un correo inexistente pero 400 ms cuando genera un token, escribe en la base y encola un correo, los atacantes pueden usar esa diferencia como una señal fiable.

También vigila filtraciones accidentales vía herramientas. Si detalles de errores internos o códigos de razón se reflejan al cliente (directamente o vía logs cliente verbosos), los atacantes pueden aprender “usuario existe” sin que la UI lo diga.

Elige un patrón de respuesta seguro para cada endpoint

La forma más rápida de reducir el riesgo de enumeración es decidir de antemano qué verá el usuario en cada flujo y cumplirlo: mismo mensaje, misma pantalla y mismo siguiente paso.

Trata cada flujo por separado (inicio, registro, restablecimiento), pero sé consistente dentro del flujo. Usa lenguaje neutral y no concluyente. Evita frases que confirmen existencia como “no encontrado”, “sin cuenta”, “ya registrado” o “el usuario no existe”.

Patrones de respuesta seguros que suelen funcionar:

• Inicio de sesión: usa un fallo genérico como “No hemos podido iniciar sesión. Revisa tus datos e inténtalo de nuevo.” Mantén las mismas opciones de ayuda disponibles siempre.
• Registro: muestra algo como “Si puedes recibir correos en esa dirección, recibirás los siguientes pasos pronto.” No cambies la UI según si la dirección ya está en uso.
• Restablecimiento de contraseña: muestra siempre “Si existe una cuenta para ese correo, enviamos instrucciones para restablecerla.” Dirige siempre a la misma pantalla de confirmación.

El texto es solo una parte. Los atacantes observan el comportamiento completo. Alinea estos elementos entre los resultados:

• Mismo patrón de códigos de estado HTTP
• Rango de tiempo de respuesta similar (evita caminos de fallo rápido evidentes)
• Misma página, botones y llamadas a la acción
• Mismo número de pasos antes de la confirmación

Un enfoque práctico para restablecer: muestra la pantalla de confirmación inmediatamente y realiza el trabajo en segundo plano. Internamente registra si se envió el correo, si rebotó, si fue suprimido o bloqueado, pero nunca lo reflejes en la respuesta.

Paso a paso: haz las respuestas indistinguibles

Necesitas un contrato claro: un endpoint debe verse igual para un llamador externo tanto si la cuenta existe como si no. Eso significa igualar el mensaje visible, el estado HTTP y la “sensación” de la respuesta.

Empieza por escribir qué tienes hoy y ve ajustando con pequeños cambios comprobables:

• Haz inventario de cada punto de entrada de auth: registro, inicio, restablecimiento, verificación de correo, “reenviar código”, además de cada cliente que los llame (web, móvil, API pública).
• Construye una matriz de respuestas para cada endpoint (éxito, contraseña incorrecta, correo desconocido, cuenta bloqueada, MFA requerido). Marca qué campos, códigos de estado y ramas de UI difieren hoy.
• Estandariza lo que el cliente puede ver: elige una estrategia de códigos de estado por endpoint y un cuerpo de respuesta que nunca confirme la existencia de la cuenta.
• Normaliza tiempos: si una ruta sale temprano, acércala a la ruta más lenta. Puedes añadir un pequeño jitter o hacer el mismo tipo de trabajo en ambas rutas.
• Actualiza el comportamiento de la UI para que coincida con el contrato: no muestres “correo no encontrado”. Muestra siempre el mismo siguiente paso.

Luego asegúralo con tests para que no se revierta con cambios de código.

Tests para mantener respuestas indistinguibles

Las comprobaciones automatizadas deben comparar salidas entre casos que antes filtraban señales:

• Asegura el mismo código de estado y la misma forma de respuesta para “correo conocido” vs “correo desconocido”.
• Asegura que los mensajes de fallo son idénticos (o igual de vagos) entre casos de fallo.
• Mide el tiempo para ambas rutas y falla el test si la brecha excede un umbral pequeño.
• Añade un test de integración que simule un pedido de restablecimiento completo y confirme que la UI no se bifurca según “cuenta existe”.

Registro, inicio y restablecimiento: plantillas de mensajes prácticas

Para prevenir la enumeración, las respuestas públicas deben verse igual tanto si la cuenta existe como si no. El truco es ser aburrido por fuera y preciso por dentro (logs, métricas, herramientas de soporte).

Plantillas de respuesta del endpoint (lo que ve el cliente)

Mantén códigos de estado y forma de mensaje consistentes. Si devuelves JSON, devuelve siempre los mismos campos.

• Inicio de sesión (cualquier fallo): 401 con { "error": "Invalid email or password." }
• Registro (aceptar la petición, incluso si el correo ya está en uso): 200 con { "message": "If you can sign up, you’ll receive an email with next steps." }
• Restablecimiento de contraseña (siempre): 200 con { "message": "If an account exists for that email, we sent reset instructions." }

En inicio de sesión es normal devolver 401 para autenticación fallida. La clave es que todos los fallos de login deben parecer iguales (correo desconocido vs contraseña incorrecta), incluyendo forma de respuesta y tiempos.

Plantillas de correo/SMS (lo que recibe el usuario)

El contenido de los mensajes también puede filtrar existencia. Evita correos que digan “No se encontró la cuenta”. Prefiere comportamiento silencioso o notas genéricas.

Ejemplos que funcionan:

• Verificación de registro: “Confirma tu correo para continuar. Si no solicitaste esto, ignora este mensaje.”
• Correo de restablecimiento: “Recibimos una solicitud para restablecer tu contraseña. Si no la solicitaste, ignora este mensaje.”
• SMS de restablecimiento: “Tu código de restablecimiento es 123456. Si no lo solicitaste, ignóralo.”

Para cuentas inexistentes, el patrón más seguro suele ser silencioso: muestra el mismo mensaje en pantalla, pero no envíes nada.

Conserva analítica y herramientas de soporte sin filtrar información

Respuestas uniformes no significan quedar a ciegas. Puedes capturar exactamente lo que pasó, solo que el detalle queda en el servidor.

Un patrón simple: devuelve el mismo mensaje al usuario, pero registra un código de razón interno estable para cada petición. Esos códigos nunca deben aparecer en respuestas API, copia de UI o logs cliente.

Ejemplos de códigos de razón internos:

• login_failed_no_user
• login_failed_wrong_password
• login_failed_mfa_required
• reset_requested_no_user
• reset_sent

Acompaña cada petición de auth con un ID de correlación generado en el servidor. Úsalo en logs y eventos de auditoría para rastrear una petición entre tu servicio de auth, el proveedor de correo y la base de datos sin exponer nada al usuario. Si muestras un ID de petición al usuario para soporte, mantenlo genérico y asegúrate de que no revele el estado de la cuenta.

Los equipos de soporte aún necesitan ayudar a usuarios reales. Mantén las herramientas de búsqueda de soporte tras autenticación de personal y con salida mínima por defecto. “Cuenta encontrada” está bien dentro de la consola; nunca debería ser algo que un llamador público pueda inferir.

Sé estricto con la PII. Registra lo mínimo necesario:

• Hash o tokenize correos en logs cuando sea posible
• Almacena correos completos solo en sistemas con políticas claras para ellos
• Mantén la retención corta salvo que el cumplimiento exija lo contrario

Añade guardarraíles: throttling, detección y controles de abuso

Los mensajes uniformes son la base, pero no toda la defensa. También necesitas guardarraíles que ralenticen a los atacantes y te ayuden a detectar patrones temprano.

Throttling y retardos progresivos

Empieza con límites de tasa que hagan la automatización costosa sin perjudicar a usuarios legítimos. Aplica límites por IP y por fingerprint de dispositivo, y añade un control cuidadoso sobre el identificador enviado (correo/teléfono) sin convertirlo en una nueva señal. Un enfoque común es mantener contadores separados y aplicar el resultado más estricto.

Tras intentos repetidos, añade retardos que crezcan con el tiempo. Mantén el comportamiento de retardos igual tanto si la cuenta existe como si no. Si añades un bloqueo, no digas “cuenta bloqueada” en el mensaje al usuario. Trata el bloqueo como estado interno.

Una configuración práctica:

• Límite por IP (ventana corta) para detener ráfagas
• Límite por dispositivo para captar IPs compartidas (cafés, oficinas)
• Límite por identificador para frenar adivinanzas dirigidas
• Retardo progresivo tras N fallos, aplicado de forma uniforme
• Bloqueo suave con cooldown y alertas internas

CAPTCHA puede ayudar, pero no lo muestres solo cuando el correo exista. Triggéralo según señales de riesgo (volumen, velocidad, pistas de automatización) y mantén el texto visible consistente.

Detección y monitorización de abusos

La enumeración tiene patrones que puedes monitorizar. Un bot puede probar cientos de correos únicos desde una sola IP, o pocos correos desde muchas IPs.

Supervisa y alerta sobre:

• Alto volumen de peticiones a login/reset/registro
• Muchos identificadores únicos por IP o dispositivo
• Intentos repetidos con baja tasa de éxito
• Picos en horas raras o desde regiones nuevas
• Patrones cruzados entre endpoints (reset y luego login con los mismos identificadores)

Errores comunes que reintroducen enumeración

Muchos equipos arreglan el texto obvio y luego filtran existencia por canales laterales. Los atacantes prueban el flujo completo, no solo la frase en pantalla.

Diferentes códigos de estado HTTP son una señal instantánea. Si un correo conocido devuelve 200 pero uno desconocido devuelve 404 (o 422), los bots lo detectarán de inmediato.

El tiempo es la siguiente pista. Una ruta toca la base de datos, envía correo o hace hashing mientras la otra sale temprano. No necesitas tiempo constante perfecto, pero evita brechas consistentes fast-fail vs slow-path.

El contenido del correo puede filtrar también. Correos de restablecimiento que incluyen nombre del plan, último inicio o saludo personalizado confirman que la cuenta es real. Mantén los correos de restablecimiento genéricos hasta que el usuario demuestre control del inbox siguiendo el token.

La lógica de UI a menudo filtra. Un prompt “Crear cuenta” que solo aparece cuando el correo es desconocido es una pista. La validación inline como “correo ya usado” ayuda a usuarios honestos, pero también es un directorio para atacantes.

Checklist rápido:

• Devuelve la misma estrategia de código de estado y el mismo JSON para ambos resultados
• Mantén el tiempo de respuesta en la misma horquilla para ambos caminos
• Evita errores a nivel de campo que impliquen existencia
• No cambies opciones de UI según si el correo existe
• Mantén los correos de restablecimiento genéricos hasta que el usuario verifique control

Comprobaciones rápidas antes de desplegar

Antes de desplegar cambios, prueba como un atacante. Un llamador externo no debería poder saber si una cuenta existe, mientras tu equipo sigue teniendo la verdad en la telemetría interna.

Checklist rápida:

• Para login y restablecimiento, confirma que devuelves el mismo patrón de códigos de estado para cuentas existentes y no existentes.
• Compara cuerpos de respuesta cara a cara. Deben tener los mismos campos, tipos de dato y una longitud similar.
• Lee las copias de correo y SMS como un desconocido. Los mensajes nunca deben confirmar que una dirección o teléfono está registrado.
• Verifica que los logs internos registran el resultado real (usuario encontrado vs no encontrado, token creado vs saltado) con un ID de petición que tu equipo de soporte pueda buscar.
• Confirma que las herramientas de soporte muestran resultados solo tras autenticación de personal, no en respuestas públicas.

Luego haz una comprobación de tiempos. Elige un endpoint (restablecimiento es un buen inicio) y prueba 20–30 peticiones con un correo que exista y otro que no. Busca una brecha clara y repetible. Si la hay, rellena la ruta rápida o mueve trabajo caro a un job asíncrono.

Ejemplo: arreglar un flujo de restablecimiento que filtraba

Un pequeño equipo SaaS empieza a recibir reportes: “Alguien sigue intentando restablecer mi contraseña”. Sus logs muestran muchos intentos de restablecimiento para direcciones que parecen listas de clientes. El patrón es clásico: alguien explora qué correos existen.

El endpoint antiguo tenía dos resultados fáciles de detectar:

• Si el correo no existía: “Correo no encontrado. Intenta registrarte.”
• Si el correo existía: “Revisa tu bandeja por un enlace de restablecimiento.”

Esa diferencia basta para confirmar cuentas válidas a escala. Incluso si la UI parece similar, pequeños cambios en código de estado, cuerpo de respuesta o tiempo aún filtran.

La solución es hacer la respuesta pública idéntica siempre y registrar el resultado real internamente con códigos de razón.

Comportamiento público (nuevo): mismo mensaje UI y mismo HTTP status para todas las peticiones, por ejemplo: “Si existe una cuenta para ese correo, enviamos instrucciones.”

Comportamiento interno (nuevo): escribe un evento estructurado para que analítica, seguridad y soporte puedan actuar:

{
  "event": "password_reset_requested",
  "email_hash": "sha256(...)" ,
  "result": "SENT" ,
  "reason_code": "OK",
  "ip": "203.0.113.10",
  "user_agent": "...",
  "request_id": "..."
}

Si el correo no existe, mantén la misma respuesta pública pero registra result: "NOOP" con reason_code: "ACCOUNT_NOT_FOUND". Si bloqueas por controles de abuso, registra reason_code: "RATE_LIMIT".

El soporte aún puede ayudar sin confirmar nada públicamente. Si alguien dice “No recibí el correo”, soporte puede buscar el último evento de restablecimiento por hash de correo o request ID. Si los eventos muestran NOOP repetidos, el usuario probablemente escribió mal la dirección. Si muestran SENT pero no hubo entrega, puedes revisar rebotes con el proveedor de correo sin cambiar lo que revela el formulario de restablecimiento.

Para validar la solución, haz una prueba antes/después: intenta restablecer con un correo conocido y uno aleatorio, luego compara códigos de estado, cuerpo de respuesta y tiempos. Deben ser indistinguibles desde el exterior, mientras tus logs siguen mostrando los resultados reales.

Próximos pasos: desplegar con seguridad y pedir una segunda opinión

Estandariza un endpoint a la vez. El restablecimiento suele ser el de mayor valor porque es fácil de sondear y con frecuencia filtra diferencias obvias. Una vez que restablecimiento sea consistente, pasa a login y luego a registro.

Antes de desplegar, mantén un plan de pruebas simple que cubra tanto tu UI web como los clientes API (apps móviles, integraciones, CLI). Sé estricto respecto a lo que significa “misma respuesta” en todos ellos.

• Prueba correos/usuarios válidos e inválidos y compara códigos de estado, forma del cuerpo y tiempos
• Prueba cuentas bloqueadas, correos no verificados y usuarios con MFA
• Confirma que la UI sigue guiando a usuarios reales sin decir “esa cuenta existe”
• Verifica que logs y métricas sigan capturando el resultado real internamente
• Revisa la localización, ya que las traducciones pueden reintroducir mensajes distintos

Si trabajas con código de autenticación generado por IA, asume que hay filtraciones ocultas (campos JSON extra, retornos tempranos, manejo de errores distinto entre clientes). FixMyMess (fixmymess.ai) se centra en diagnosticar y reparar este tipo de fallos en producción, incluyendo endurecer respuestas de auth mientras mantiene telemetría interna útil para soporte y seguridad.