Colocar la dirección IP en el token web JSON o la cookie de sesión

Veo algunas cosas en que pensar:

1. Debería asegurarse de que un intento de inicio de sesión solo sea válido cuando   El cliente le envía una cookie de sesión válida. De lo contrario, el atacante.   simplemente no puede enviar una cookie de sesión y felizmente generará una   Una nueva para él en cada intento de inicio de sesión. Ese parece ser un problema difícil de resolver. ¿Cómo obliga a un atacante a enviarle una cookie si no quiere?

2. ¿Por qué asume que todos los intentos de inicio de sesión provendrán de la misma dirección IP? ¿Qué sucede si tienes un ataque lanzado desde múltiples IPs?

3. ¿Qué sucede si un atacante no intenta atacar a un solo usuario, sino que intenta un rango completo de nombres de usuario y contraseñas? Esto significa que no detectará un ataque en curso, porque no habrá múltiples intentos de inicio de sesión para cualquier usuario en una sucesión rápida.

OMI, no puede evitar mantener un estado persistente del lado del servidor acerca de la frecuencia global de las solicitudes a su punto final de inicio de sesión (o de hecho a cualquier punto extremo), independientemente de quién parezca ser el cliente y si obtiene una cookie de sesión o no.

Los paquetes de código abierto (los estables y reputados que se envían con las distribuciones principales) representan un riesgo mucho menor que los consejos de código abierto ;) Hay una gran cantidad de consejos erróneos. Oh por cierto, este consejo es bastante legítimo! ;)

Por lo tanto, una buena dosis de escepticismo (no paranoia) es buena para la seguridad y usted ha tenido un buen comienzo.

En general:  1. Necesitas múltiples protecciones para trabajar juntos. No mire solo una amenaza de forma aislada, aunque examine al final si está cubriendo todas las amenazas al menos hasta cierto punto.  2. La prevención completa en todas las circunstancias es excelente, pero la mayoría de las veces, es suficiente con elevar las barreras para que sea antieconómico para los atacantes que no son objetivos.

Más específicamente:

1. En general, odio los captchas como usuario. Así que no los uso en sistemas que desarrollo. Si debo soportar una, una barrera simple (ver el principio 2 más arriba) como la que usa CloudFlare es la que prefiero. La última comprobación es una combinación de análisis del lado del servidor (cómo las solicitudes de bot generalmente vienen a frecuencias diferentes a las de los humanos), algunos JS para detectar las características del navegador (paro general de bots con suplantación de cadenas UA), un pequeño retraso de un segundo por segundo para ralentizar a los bots pero ni siquiera es perceptible por los humanos, etc.
2. Mencionó que usaría un captcha cuando detecte repetidos intentos fallidos de inicio de sesión. Esa es una buena manera de hacerlo, e indica que está utilizando las verificaciones del lado del servidor.
3. Se pueden realizar más verificaciones del lado del servidor (incluidas las verificaciones de la dirección IP, si lo desea), aunque no se recomiendan debido a problemas de roaming / dirección IP dinámica mencionados por @ blownie55 y @Pascal. No es necesario almacenar la dirección IP en las cookies. Siempre puede obtenerlo de la solicitud y verificarlo con las propiedades almacenadas en la sesión.
4. En algunos casos, "bloqueamos temporalmente las direcciones IP de ataque" cuando detectamos un ataque de fuerza bruta en progreso. Cualquier cosa de 30 minutos a 1 día debería funcionar, dependiendo de la naturaleza de los atacantes en su dominio de activos. Los dominios más riesgosos en general necesitan un bloqueo más prolongado; Los dominios de uso de alto volumen necesitan un bloqueo más corto; Los dominios riesgosos de alto volumen necesitan una filosofía para intervenir. :)

Espero que esto ayude.