Defensas graduales sin castigar al usuario legítimo

Una defensa de un solo escalón obliga a elegir un umbral imposible: si es bajo, castiga a clientes que tienen picos legítimos; si es alto, deja pasar casi todo. Una respuesta gradual reparte la decisión. Primero solo se observa y se registra; después se frena con una respuesta 429 que dice cuánto esperar; luego se pide algo que a una persona le cuesta poco y a un programa más; y solo al final se corta. Cada escalón sube el coste para quien abusa y apenas lo nota quien usa la aplicación con normalidad, y los primeros dejan ver a quién se iba a castigar antes de castigarlo.

Hay un caso en el que cortar es especialmente peligroso: el bloqueo de una cuenta por fallos de inicio de sesión. Si basta con fallar unas cuantas veces contra una cuenta para bloquearla, cualquiera que conozca el nombre de usuario puede dejar a su dueño fuera, y el atacante convierte la defensa en su herramienta. Para los fallos de inicio de sesión se prefiere un retraso que crece con cada intento, contado por cuenta, junto con avisos a la dueña.

Abre el laboratorio y lee politica-propuesta.yaml en la carpeta guanenta-graduales. Fíjate en el ámbito, en qué cuenta cada escalón y en la línea de excepciones. Después abre simulacion-semana-anterior.txt y crúzala con cuentas-de-referencia.txt: la simulación dice qué le habría pasado a cada cuenta; la referencia, quién es cada una. Una integración no resuelve desafíos ni llama a soporte: si se bloquea, se rompe en silencio a medianoche.

Una política se evalúa con dos números: a cuántos abusadores frena y a cuántos legítimos castiga. Cuenta las cuentas legítimas que, según la simulación y la referencia comercial, habrían terminado bloqueadas, por volumen o por fallos de acceso. Un desafío en el navegador molesta pero no bloquea: no lo cuentes. La cuenta creada hace una semana que solo lee precios no es legítima.

Mira las dos cuentas de la simulación que llegan al escalón por fallos de acceso. Una es un encargado nuevo que se equivocó de contraseña; la otra es la tienda de la primera sala, contra la que alguien que tenía su contraseña reutilizada estuvo fallando el código de verificación desde muchas direcciones. En los dos casos la política deja fuera a quien no hizo nada malo, y en el segundo lo hace a petición del atacante.

Al final de la simulación hay una línea que no es de ninguna cuenta: la sesión anónima de la sala anterior. La política cuenta solo por cuenta de sesión iniciada, así que lo anónimo no existe para ella; y aunque contara, esa sesión pide muy por debajo de cualquier umbral de volumen. Una defensa contra la extracción lenta no se basa en volumen sino en las señales de comportamiento y en lo que la información vale. Así que la política tiene que corregirse por los dos lados: dejar de castigar a los legítimos y empezar a ver a quien sí abusa.