Credential stuffing es repetir, contra tu login, pares de email y contraseña filtrados de otros sitios. La gente reutiliza contraseñas, así que una pequeña parte de cualquier lista filtrada funciona casi en cualquier lado. El atacante no necesita vulnerar tu sistema; necesita volumen y un formulario de login que responda rápido.
Cómo se ve en tus logs
- Una tasa de fallos que se dispara. Los logins normales suelen funcionar. Una tanda de stuffing falla diecinueve de cada veinte veces.
- Muchas cuentas, pocos intentos en cada una. A diferencia de la fuerza bruta, cada cuenta se prueba una o dos veces, así que el bloqueo por cuenta nunca se activa.
- Muchas direcciones. Los intentos llegan desde pools de proxies residenciales, así que bloquear las IPs más frecuentes casi no cambia nada.
- Logins sin página. El endpoint de login se llama directo, desde clientes que nunca cargaron la página de login.
- Ritmo de máquina. Solicitudes a cadencia constante, a horas en que tus clientes duermen.
Por qué las defensas de siempre no alcanzan
El rate limit por IP lo vencen pools de proxies con miles de salidas. El bloqueo de cuentas perjudica más a tus clientes que al atacante, y puede convertirse en una forma de bloquear gente a propósito. Los CAPTCHAs los resuelven servicios de pago por una fracción de centavo. Cada uno suma fricción para las personas reales y un costo pequeño para los bots.
Juzga al cliente, no solo la solicitud
Una herramienta de stuffing cambia IP y User-Agent en cada solicitud. Lo que le cuesta falsificar es un navegador completo y consistente, que cargó tu página, ejecutó tu script y se comporta como una persona durante la sesión:
- un token firmado de la página, ausente o compartido entre muchas sesiones;
- señales de automatización y fingerprints de navegador que no cuadran;
- un dispositivo o token probando muchas cuentas distintas;
- reintentos que siguen pese a los errores, algo que una persona no hace.
Dónde poner la verificación
Pregunta antes de verificar la contraseña, para que un bot nunca sepa si un par funciona:
- bot_high: responde como si la contraseña fuera incorrecta. La herramienta no aprende nada, y tu cliente ni se entera.
- bot: pide un segundo factor o un código por email antes de abrir la sesión.
- todo lo demás: el login normal.
Responderle a un bot con el mismo "contraseña incorrecta" que vería una persona importa: una página de bloqueo distinta le avisa al atacante que cambie de táctica.
Después del login
Cuéntale a tu verificación de bots qué pasó después. Un login que luego hace un pedido real, o un contracargo que prueba lo contrario, es evidencia que ningún header puede falsificar, y afina la próxima decisión sobre el mismo visitante.