¿En qué casos debería bloquear a un usuario después de un cierto número de intentos fallidos?

1

Tengo una aplicación web. Los usuarios existentes pueden invitar a nuevos usuarios enviando un correo electrónico a la aplicación web.

Si el usuario falla 4 veces consecutivas, bloqueo la cuenta durante 5 minutos.

Actualmente no hay información importante en la aplicación.

El problema con la política actual es:

  1. Si un usuario malicioso B quiere bloquear al usuario A, podría intentar iniciar sesión con el nombre de usuario de A 4 veces cada 5 minutos. Entonces A no pudo iniciar sesión en la aplicación.
  2. Podría bloquear si las 4 cámaras fallan desde la misma IP (y solo bloquean para esa IP). Pero el usuario malicioso puede cambiar su IP. No sé cómo, pero potencialmente él puede llenar mis recursos (porque tengo que hacer el recuento para cada IP)
  3. Puedo poner captcha, pero no estoy seguro de cuánta ayuda.

¿Puedes ayudarme? ¿Qué puedo leer o hacer?

    
pregunta Emilio Platzer 02.07.2018 - 02:57
fuente

2 respuestas

1

Tienes que protegerte ante la mayor amenaza. Tienes 2 escenarios:

  1. Usuario / troll malicioso que intenta denegar el servicio a otro usuario. Esta es una preocupación relativamente común, pero es raro verla en la práctica
  2. Cuentas de forzoso brutal de atacantes: aunque su sitio no tenga datos útiles para un atacante, las credenciales en sí mismas son las mismas que muchos usuarios reutilizan contraseñas

El escenario 2 es, para la mayoría de los sitios, mucho más probable y por esa razón es bueno tener una política de bloqueo. Captcha (si se implementa correctamente) sería útil para evitar que los bots intenten iniciar sesión de manera adicional en el escenario 2, después de x número de intentos se activaría una pantalla de captcha, derrotando a un bot pero los humanos podrían desbloquearlo. Configurar alertas para fallos de inicio de sesión repetidos es una buena idea para que pueda hacer un seguimiento de este tipo de cosas, al igual que alertar a los usuarios por correo electrónico cuando sucede para que el usuario pueda decirle si están actuando o no.

Si cree que el escenario 1 es relativamente probable para su sitio, entonces es lógico poder filtrar el acceso desde un conjunto particular de direcciones IP. La mayoría de los usuarios malintencionados no tienen una botnet a su disposición que usarían solo para mantener al usuario bloqueado, por lo que probablemente vería un patrón. Sin embargo, sería más difícil usar este método contra un atacante sofisticado, solo usar TOR sería suficiente para anular el filtrado. Una buena parte de la protección que podría usar para el escenario 1 está en su diseño de detalles de inicio de sesión, no permite el inicio de sesión con nombres de usuario y, en su lugar, utiliza direcciones de correo electrónico. De esa manera, si a un troll no le gusta SmarterPerson1887, tendrían que conocer la dirección de correo electrónico de ese usuario, lo cual es mucho menos probable.

    
respondido por el GdD 02.07.2018 - 14:59
fuente
1

Según lo solicitado, inventaré mi propia respuesta.

  

Si un usuario malicioso B quiere bloquear al usuario A, podría intentar iniciar sesión con el nombre de usuario de A 4 veces cada 5 minutos. Entonces A no pudo iniciar sesión en la aplicación.

Ese es el problema al bloquear cuentas: no sabes si el usuario es realmente legítimo hasta que pasaron la pantalla de inicio de sesión. Por lo tanto, no puede asumir que el usuario A está intentando iniciar sesión en la cuenta A. Si no es un problema para los sitios web clásicos, puede ser muy problemático para los juegos web (puedo bloquear otra cuenta justo antes de atacarlos, por lo que no pueden defenderse). / p>

Por lo general, la razón por la que el webmaster quiere bloquear cuentas es:

  

Quiero evitar una fuerza bruta

Pero si se rompe su base de datos, se puede realizar un ataque sin conexión y evitar el enfoque de fuerza bruta de las cuentas de bloqueo.

Además, en mi experiencia, los atacantes rara vez fuerzan una cuenta directamente. ¿Por qué? Porque requiere un poco de tiempo para obtener la contraseña correcta (si se eligió bien). Por lo tanto, los atacantes proceden de otra forma: enumeran todas las cuentas en el servidor y prueban las contraseñas más utilizadas en cada una de ellas, cuenta por cuenta. De alguna manera, en lugar de probar todas las contraseñas en una cuenta, prueban una contraseña en todas las cuentas. Por lo tanto, su sistema de fuerza bruta es ineficiente.

OMI, una mejor manera de evitar la fuerza bruta es simplemente hacer que la comprobación de hash sea más larga (1 segundo) , usando iteraciones suficientes para que tome 1 segundo (o así) por verificación. Haciendo esto:

  • Si un atacante apunta a una cuenta, necesitarán miles de millones de millones de años para violarla si la contraseña fue bien elegida. Si realizan un ataque paralelo, todavía necesitarán miles de millones de años
  • Ya debería tener alguna mitigación de DDoS, por lo que en caso de que un ataque requiera demasiados recursos en su servidor, entonces estará seguro (es otro campo que las cuentas de fuerza bruta). Por ejemplo, puede "priorizar" recursos, dándoles primero a los usuarios que han iniciado sesión y dejando la mitad de los restantes a los que no han iniciado sesión
  • Si un atacante intenta una contraseña en todas las cuentas, aún necesitará mucho tiempo para probar los miles de cuentas de usuario que tiene
  • Si se rompe la base de datos, el ataque sin conexión aún necesitará mucho tiempo, lo suficiente para que los usuarios actualicen sus contraseñas
  • Es sin estado, por lo que no tendrá problemas para almacenar quién hizo un intento de inicio de sesión, en qué cuenta, etc.
  • 1 segundo es lo suficientemente corto como para que los usuarios normales no lo noten
respondido por el Xenos 02.07.2018 - 15:53
fuente

Lea otras preguntas en las etiquetas