Implicación de seguridad de decirle al usuario que no puede iniciar sesión debido a demasiados intentos de IP

  

Absolutamente no envíe mensajes al usuario final diciéndoles por qué falló el inicio de sesión. Le está dando a un atacante potencial información crítica para ayudarlo a atacar su aplicación.

Por otra parte, no decirle a un usuario por qué falló su inicio de sesión es un desastre potencial de usabilidad.

Si no aclara si la IP del usuario fue prohibida o si el usuario usó una contraseña incorrecta, podría entrar en pánico, ya que les parece que alguien accedió a su cuenta y cambió la contraseña para bloquearla. Si mi inicio de sesión con una contraseña completada falla, lo primero que pienso es en un robo en lugar de un bloqueo de IP.

Además, un mecanismo de bloqueo de IP ingenuo puede ser ineficaz e introducir problemas adicionales. Es potencialmente trivial para omitir para un atacante con suficientes recursos y alguien que comparte una dirección IP con otros usuarios podría abusar de la prohibición de IP para bloquear a otros. En cambio, un CAPTCHA después de n intentos fallidos por IP puede ser una solución más suave y más apropiada para su aplicación.

También vea:

• ¿Es una buena práctica prohibir una dirección IP si se realizan demasiados intentos de inicio de sesión?
• ¿Por qué la gente ¿Usa las prohibiciones de direcciones IP cuando las direcciones IP cambian a menudo?

Hay un beneficio de seguridad al proporcionar mensajes genéricos que no se han mencionado.

Alice está tratando de forzar una cuenta en el servidor de Bob. Para los primeros intentos, Alice recibe el mensaje "Falló el intento de inicio de sesión". En el siguiente intento, obtiene "Demasiados intentos de inicio de sesión de esta dirección IP". Ahora sabe que (a) todas las credenciales que probó hasta este momento no eran válidas, y (b) necesita hacer algo diferente antes de hacer más intentos.

¿Pero qué pasa si Bob no cambia el mensaje? Alice continuará con la fuerza bruta y continuará obteniendo el "intento fallido de inicio de sesión" genérico en cada intento incluso si las credenciales son correctas . Si sucede que ella intenta las credenciales correctas, Bob rechazará el intento porque se ha excedido el límite de IP, pero Alice no sabrá que esa es la razón y tendrá que tratarlo como un intento incorrecto (a menos que tenga otros forma de saber cuál está más allá del alcance de esta pregunta). Su única opción es continuar con la búsqueda, sin saber si ella ya ha localizado y ha pasado las credenciales correctas.

Tenga en cuenta que este beneficio es seguridad a través de la oscuridad ya que confía en que Alice no sepa la política de bloqueo de IP de Bob. Dependiendo de la configuración, esta información puede ser trivial de obtener. Por ejemplo, si Alice tiene acceso a otra cuenta en el sistema (fácil si acepta el registro de una cuenta pública), entonces puede usar prueba y error para ver si un intento correcto finalmente es rechazado después de demasiados intentos incorrectos.

Otras respuestas han explicado la compensación entre la seguridad y la usabilidad, por lo que no me molestaré en repetir eso.

Sí, técnicamente está devolviendo información que podría ser utilizada por un atacante para afinar una red de bots de fuerza bruta. Además, no estoy seguro de cuán útil será el mensaje de error "Para muchos intentos de inicio de sesión desde esta IP" para un usuario estándar. También se debe tener en cuenta que cualquier atacante experimentado comenzará a notar un tipo de respuesta cambiante o una diferencia de tiempo, y probablemente, de todos modos, descubrirá lo que está sucediendo.

Es posible que desee considerar el uso de un servicio como CloudFlare. Tienen una API de secuencias de comandos que puede insertar dinámicamente una página intersticial o actualizar una regla WAF en ciertos escenarios. Troy Hunt tiene un buen tutorial donde hace esto para Windows Azure utilizando las funciones de Azure.

En este caso, la seguridad y la facilidad de uso son objetivos contrarios. Si bien la implementación más segura no ofrecería comentarios, también sería menos fácil de usar. Debe decidir qué tan susceptible es su sistema al uso brutal de los inicios de sesión, qué otras mitigaciones están implementadas y qué tan efectiva es la mitigación específica cuando se evalúa contra los inconvenientes para el usuario.

Por ejemplo, si estuviera diseñando el inicio de sesión para un dispositivo de consumo, lo haría lo más fácil de usar posible al tener comentarios detallados e introducir mitigaciones adicionales para compensar. Si estuviera diseñando el inicio de sesión de HSM, entonces no ofrecería comentarios y un tiempo de espera excesivo en todo el dispositivo.

Todo depende de lo que estés construyendo. Si es un blog o cualquier otro sitio sofisticado donde no es realmente importante rechazar intentos legítimos, y donde realmente no confía en la robustez de la aplicación, debería protegerla de cualquier cosa que pueda ser un ataque y nunca decir por qué. usted rechaza un inicio de sesión.

Si está creando una aplicación profesional y espera que los accesos profesionales no limiten los accesos desde una única IP si su aplicación es lo suficientemente robusta. Si lo hace, asegúrese de informar al usuario de la razón y configurar un hot line que responda razonablemente (a lo sumo 1 día hábil para leer y comprender un mensaje, e iniciar una acción correctiva si es necesario ). Debido a que es común que las organizaciones grandes configuren un único proxy saliente para todos sus accesos HTTP y HTTPS. Es posible que tenga miles de empleados en diferentes ubicaciones en un país, todos con aparentemente la misma dirección IP. Una lista blanca que permita conexiones ilimitadas desde proxies conocidos es suficiente, pero debe estar listo para cambiarlo rápidamente si uno de sus clientes hace que su red evolucione y cambie su dirección proxy.