Evitar ataques de fuerza bruta en un formulario de inicio de sesión basado en la web

5

Mi formulario de inicio de sesión utiliza Ajax, por lo que no es necesario volver a cargarlo si la contraseña es incorrecta. Un script PHP procesa la solicitud y crea la sesión si las credenciales son correctas. Mi idea es tener el script PHP en suspensión para mitigar un ataque de fuerza bruta. Al principio no dormía, pero después de eso no estoy seguro.

¿Durante cuánto tiempo un formulario requiere que un atacante espere hasta que pueda probar la siguiente contraseña? ¿También se recomiendan los bloqueos completos? Si es así, ¿después de cuántos intentos?

    
pregunta Celeritas 29.04.2013 - 22:30
fuente

3 respuestas

9

Dado que HTTP es un protocolo sin estado, no hay un concepto de tiempo de espera entre intentos. El atacante puede simplemente generar múltiples procesos e intentar varias contraseñas simultáneamente.

Una forma común de solucionar el problema y reducir el impacto en su servidor es mediante la implementación de una política de bloqueo, en la que mantiene un contador para rastrear los intentos de contraseña incorrecta para un nombre de usuario determinado durante un período específico de tiempo (5 los intentos incorrectos en 5 minutos son un valor predeterminado común) y simplemente deje de intentar autenticar las solicitudes con ese nombre de usuario durante los próximos minutos.

    
respondido por el Xander 29.04.2013 - 22:43
fuente
6

Un pirata informático puede generar fácilmente varias llamadas AJAX en paralelo, esto pasará por alto tu sueño. Y puede terminar atascando los recursos del servidor. En su lugar, haga lo siguiente:

  • Comience a mostrar CAPTCHAs después de tres intentos incorrectos desde una IP
  • Después de un intento incorrecto, bloquee todas las nuevas solicitudes de inicio de sesión a su servidor desde esa IP durante un período de tiempo. Incrementa esto en cada intento fallido.
  • Mantenga un registro y observe los picos de actividad. Si alguien está tratando de hacer fuerza bruta, debes tomar nota de eso y contrarrestarlo.
respondido por el Manishearth 29.04.2013 - 23:36
fuente
1

CUENTAS DE USUARIO

En algunos casos, una política de bloqueo (o el uso de la función de suspensión php) para proteger un formulario de inicio de sesión podría ser incluso peor (o mucho peor) que un ataque de fuerza bruta, en particular si el atacante tiene acceso a los datos de inicio de sesión de la cuenta de usuario: por ejemplo, en los casos en que los nombres de usuario públicos se utilizan para la autenticación, lo cual es malo en general, si es evitable. El atacante podría bloquear a los usuarios registrados una y otra vez (DOS), lo que llevaría a un verdadero desastre. Nunca hagas eso en un sitio web público. Probablemente sea mucho más fácil para un atacante explotar un sistema de bloqueo de cuenta basado en intentos de inicio de sesión, que para un desarrollador crear uno eficaz. Una mejor solución es mantener las buenas prácticas: ocultar la mayor cantidad de información posible, como de costumbre, mientras obliga a los usuarios a crear buenas contraseñas. De esta manera, los ataques de fuerza bruta podrían ser totalmente inútiles: el atacante necesitará demasiados recursos para lograr algo. En este escenario, por ejemplo, use correos electrónicos solo para iniciar sesión (o cualquier otro dato de usuario que no sea público), nunca nombres de usuario públicos, y nunca los haga visibles y recopilables para otros usuarios o público. Pero no aplique una política de bloqueo en las cuentas de usuario.

IPs

Un buen ataque de DOS se realiza desde muchos ips diferentes. Dicho esto, podría aplicar una política de bloqueo en el servidor web para evitar los ataques de DOS y Brute Force detectando solicitudes excesivas de una sola IP (solicitudes de cualquier tipo, y no solo en una página o formulario de inicio de sesión). Los hospedajes compartidos a menudo adoptan políticas de este tipo y, por lo general, usted no tiene que preocuparse demasiado ya que no puede cambiarlas. Pero si tiene que configurar un servidor dedicado, esto puede ser un poco más complicado: este es un tema para los administradores de servidores, más que para los desarrolladores web. Si usa Apache, podría estar interesado en algo como esto: enlace

Y: enlace

    
respondido por el e.a. 06.07.2013 - 00:44
fuente

Lea otras preguntas en las etiquetas