Cada página de login pública comienza a ser escaneada por herramientas automatizadas poco después de ponerse en marcha. Los atacantes prueban nombres de usuario y contraseñas previamente filtrados, martillan una sola cuenta con intentos de contraseña o usan bots para abusar del formulario de login.
Estos ataques no se ven iguales. A veces muchos intentos provienen de una sola dirección IP. A veces el mismo nombre de usuario se reintenta desde muchas fuentes diferentes. A veces se aplican contraseñas filtradas a miles de cuentas diferentes a baja velocidad, en un patrón distribuido.
Por eso las defensas estáticas se quedan cortas. Bloquear solo por IP pierde los ataques distribuidos y puede bloquear erróneamente a usuarios reales que vienen a través de redes compartidas. Bloquear solo por cuenta le da a los atacantes otra ventaja — pueden bloquear muchas cuentas y causar un denial of service. Forzar CAPTCHA en cada login arruina la experiencia del usuario real.
El mayor error es dejar la evaluación de bot y riesgo en el momento del login completamente a un servicio de nube de terceros. Ese modelo crea dependencia externa, costo por usuario o por evaluación, problemas de visibilidad de datos y un punto de ruptura adicional en la ruta de autenticación.
La protección del login no debería ser un muro uniforme. Debería ser una capa de seguridad local que aumenta la fricción a medida que aumenta el riesgo, responde en función del origen y el objetivo del ataque, y no penaliza innecesariamente a los usuarios reales.
Porque proteger la página de login no es solo detener al atacante — también es mantener al usuario real capaz de continuar su trabajo de forma segura.
Fricción gradual, política de múltiples alcances y un desafío alojado en el servidor — todo en la plataforma que ya posee.
Cada política ejecuta tres umbrales: una advertencia que aparece en el registro de auditoría, un desafío CAPTCHA que filtra la automatización sin bloquear a los humanos, y un bloqueo que cierra la puerta por completo. Los usuarios legítimos rara vez ven el segundo nivel y casi nunca el tercero; los atacantes escalan rápidamente.
Cada política se aplica en uno de tres alcances: por IP fuente, por nombre de usuario, o por ambos juntos. Un ataque de fuerza bruta contra una cuenta desde una IP queda detectado por el alcance IP; el credential stuffing a través de muchos nombres de usuario desde IPs rotatorias queda detectado por el alcance de nombre de usuario; el alcance combinado gestiona los ataques dirigidos que mezclan ambos.
El desafío CAPTCHA se genera del lado del servidor como imagen, con cinco niveles de dificultad, un conjunto de caracteres que omite los caracteres confusos (I, L, O, 0, 1), y colores, dimensiones y ruido configurables. Sin Google reCAPTCHA, sin Cloudflare Turnstile, sin cargo por evaluación — y el momento más sensible de la autenticación nunca sale de su perímetro.
Los contadores de bloqueo se coordinan con el mismo rastreo de intentos utilizado por cada canal MFA. Un usuario no puede forzar un factor mientras otro factor espera en un intento paralelo, y un CAPTCHA activado en el paso de contraseña se propaga al resto del flujo que protege la misma identidad.
Los primitivos de defensa en detalle, más la hoja de ruta que los profundizará.
Cada política está vinculada a uno de tres alcances. El alcance IP detecta a un solo atacante que martilla muchas cuentas desde una red. El alcance de nombre de usuario detecta el credential stuffing donde cada intento rota la IP fuente. El alcance combinado detecta el caso dirigido donde un atacante conocido se enfoca en una cuenta específica desde una red específica.
Cada política ejecuta tres umbrales que escalan en orden. El umbral de advertencia marca la actividad sospechosa en el registro de auditoría sin afectar al usuario. El umbral de CAPTCHA pone un desafío de imagen alojado en el servidor frente al siguiente intento. El umbral de bloqueo cierra la puerta durante una duración configurable — y el orden, los valores y la ventana de decaimiento son todos por política.
Los CAPTCHAs se generan localmente como imágenes — cinco niveles de dificultad desde indicaciones de legibilidad ligeras hasta distorsión pesada, colores y dimensiones configurables para coincidir con la marca, y un conjunto de caracteres que omite intencionalmente los caracteres visualmente similares (I, L, O, 0, 1) para mantener la experiencia del usuario legítimo limpia.
La protección del login se genera, se sirve, se valida y se audita completamente en la plataforma. Sin cargo por evaluación, sin dependencia externa, sin implicación de privacidad de enviar cada intento de login a un proveedor, y sin servicio de scoring opaco sentado entre sus usuarios y su autenticación.
Los intentos de contraseña fallidos, los desafíos MFA fallidos y las respuestas CAPTCHA fallidas alimentan contadores coordinados por alcance de política. Un atacante no puede forzar un factor mientras un intento paralelo espera en otro, y un bloqueo activado en un paso se propaga a cada canal que protege la misma identidad.
Cada política define una ventana de decaimiento. Los intentos fallidos más antiguos que la ventana dejan de contar para los umbrales actuales, por lo que un usuario legítimo que escribió mal su contraseña tres veces la semana pasada no comienza hoy ya en el nivel CAPTCHA. La ventana, la forma de decaimiento y los umbrales son todos ajustables por política.
Cada intento de login — éxito, advertencia cruzada, CAPTCHA activado, bloqueo disparado — escribe una entrada de auditoría estructurada con timestamp, IP fuente, user agent, alcance y resultado de política. La información del destinatario (email, teléfono) se enmascara en el flujo de auditoría por defecto para que el registro de auditoría no se convierta en una ruta de filtración secundaria.
Un motor de correlación planificado vinculará los contadores de intentos entre servicios, para que un atacante que prueba credenciales contra una aplicación de bajo valor no pueda luego pasar a una de alto valor con un historial limpio. Los feeds de reputación de IP se conectarán al mismo motor de política para escalar automáticamente la fricción para las redes maliciosas conocidas.
La mecánica que hace que la defensa gradual sea invisible para los buenos usuarios y clara para los atacantes.
El color de fondo, el color del texto, el ancho, el alto, el tamaño de fuente, el espaciado de caracteres, las líneas de ruido y los puntos de ruido son todos configurables. El desafío puede coincidir con la identidad visual del portal de login que protege sin revelar que hay un servicio externo involucrado — porque no hay nada externo involucrado.
El conjunto de caracteres predeterminado omite I, L, O, 0 y 1 — caracteres que son fáciles de confundir entre sí en forma distorsionada. Los usuarios legítimos resuelven los CAPTCHAs más rápido y con menos reintentos; el valor defensivo contra los solucionadores automatizados se preserva en cada nivel de dificultad.
El umbral de advertencia, el umbral de CAPTCHA, el umbral de bloqueo, la ventana de decaimiento y la duración del bloqueo son todos configurables por política. Una interfaz de gestión de usuarios tiene diferentes tolerancias que un login de servicio de asistencia público o una consola de administración; el mismo motor los sirve con números diferentes.
Los contadores y el estado de bloqueo viven en Redis, por lo que cualquier pod gateway puede ver el conteo actual de intentos para cualquier alcance. Los despliegues escalados horizontalmente ven un estado consistente sin sobrecarga de coordinación, y una decisión de bloqueo tomada en un pod es inmediatamente visible para todos los demás pods.
Un usuario bloqueado espera ya sea a que el bloqueo expire en su propio reloj o es desbloqueado por un administrador a través de la interfaz de administración del gateway. La acción de recuperación se audita en sí misma; un desbloqueo de emergencia durante un incidente es un evento rastreable en lugar de una solución invisible.
Los umbrales adaptativos que se ajustan automáticamente cuando una fuente de inteligencia de amenazas upstream señala mayor riesgo — redes maliciosas conocidas, campañas activas de credential stuffing, listas de credenciales filtradas — están en la hoja de ruta. El mismo motor de política recibe la señal; el mismo registro de auditoría registra el cambio.
Un atacante con una lista de nombre de usuario/contraseña filtrada rota las IPs y prueba cada par contra la página de login. Las políticas de alcance de nombre de usuario detectan este patrón — los contadores suben por cuenta, el nivel CAPTCHA filtra la automatización y el bloqueo cierra la puerta para los objetivos repetidos.
Un solo atacante, una sola IP fuente, una sola cuenta objetivo, muchas adivinanzas. Las políticas de alcance IP detectan esto en segundos — la advertencia aparece en la auditoría, el nivel CAPTCHA filtra los intentos con script y la duración del bloqueo se multiplica lo suficientemente rápido como para hacer que el ataque sea antieconómico.
Los agentes automatizados intentan iniciar sesión para hacer scraping, spam o esperar una cuenta desbloqueada. El nivel CAPTCHA es exactamente donde se detectan estos — generado localmente, validado localmente y completamente fuera del alcance de los servicios de resolución automática de CAPTCHA que apuntan a los desafíos SaaS externos.
PCI DSS, HIPAA, GDPR e ISO 27001 requieren evidencia de que el monitoreo de logins fallidos está en su lugar, con umbrales y registros de auditoría. El flujo de auditoría por intento le da al auditor una única línea de tiempo para revisar, con umbrales expresados como configuración en lugar de prosa escrita.
Fricción gradual de tres niveles, cobertura de política de tres alcances y CAPTCHA alojado en el servidor — todo en la plataforma que ya posee. Recorreremos un despliegue en vivo en sus aplicaciones.