security - Aceleración de los intentos de inicio de sesión
language-agnostic login (5)
Creo que deberá mantener el recuento fuera de la sesión; de lo contrario, el ataque trivial consistirá en borrar las cookies antes de cada intento de inicio de sesión.
De lo contrario, el recuento y el bloqueo son razonables, aunque una solución más fácil sería tener un tiempo de espera duplicado entre cada error de inicio de sesión. es decir, 2 segundos después del primer intento de inicio de sesión, 4 segundos después del siguiente, 8 etc.
Implementa el tiempo de espera rechazando inicios de sesión en el período de tiempo de espera, incluso si el usuario proporciona la contraseña correcta, simplemente responda con texto legible por humanos que indique que la cuenta está bloqueada.
También supervise el mismo usuario de IP / diferente y el mismo usuario / IP diferente.
(Esto es en principio una pregunta independiente del idioma, aunque en mi caso estoy usando ASP.NET 3.5)
Estoy usando el control de inicio de sesión ASP.NET estándar y me gustaría implementar la siguiente lógica de aceleración de intentos de inicio de sesión fallida.
- Maneje el evento
OnLoginErrory mantenga, en Session , un recuento de intentos fallidos de inicio de sesión - Cuando este recuento llega a [algún valor configurable] bloquee intentos de inicio de sesión adicionales desde la dirección IP de origen o para ese usuario / esos usuarios durante 1 hora
¿Esto suena como un enfoque sensato? ¿Me estoy perdiendo un medio obvio por el cual podrían evitarse tales controles?
Nota: La sesión de ASP.NET está asociada con el navegador del usuario utilizando una cookie
Editar
Esto es para un sitio de administración que solo se utilizará desde el Reino Unido y la India
Esto también podría afectar a tus usuarios genuinos. Por ej. en países como Singapur, hay un número limitado de ISP y un conjunto más pequeño de IP que están disponibles para usuarios domésticos.
Alternativamente, podría insertar un captcha después de x intentos fallidos para frustrar script kiddies.
La respuesta aceptada, que inserta retrasos crecientes en intentos de inicio de sesión sucesivos, puede tener un rendimiento muy bajo en ASP.NET según cómo se implemente. ASP.NET utiliza un grupo de subprocesos para atender las solicitudes. Una vez que se haya agotado este grupo de subprocesos, las solicitudes entrantes se pondrán en cola hasta que esté disponible un subproceso.
Si inserta el retraso utilizando Thread.Sleep (n), vinculará un subproceso de grupo de subprocesos de ASP.NET durante la demora. Este hilo ya no estará disponible para ejecutar otras solicitudes. En este escenario, un simple ataque de estilo de DOS sería seguir enviando su formulario de inicio de sesión. Finalmente, cada subproceso disponible para ejecutar solicitudes estará inactivo (y durante períodos de tiempo crecientes).
La única forma en que puedo pensar para implementar correctamente este mecanismo de retraso es usar un controlador HTTP asíncrono. Consulte Tutorial: Crear un controlador HTTP asíncrono . La implementación probablemente necesite:
- Intento de autenticación durante BeginProcessRequest y determinar el retraso en la falla
- Devuelve un IAsyncResult exponiendo un WaitHandle que se activará después del retraso
- Asegúrese de que WaitHandle se haya activado (o bloquee hasta que haya sido) en EndProcessRequest
Lo último que desea hacer es almacenar todos los intentos de inicio de sesión fallidos en una base de datos, que funcionará lo suficientemente bien, pero también hace que sea extremadamente trivial para los ataques DDOS para bajar su servidor de base de datos.
Probablemente esté utilizando algún tipo de caché del lado del servidor en su servidor web, memcached o similar. Esos son sistemas perfectos para usar para realizar un seguimiento de los intentos fallidos por dirección IP y / o nombre de usuario. Si se excede un determinado umbral para los intentos fallidos de inicio de sesión, puede decidir desactivar la cuenta en la base de datos, pero guardará un montón de lecturas y escrituras en el almacenamiento persistente para los contadores de inicio de sesión fallidos que no necesita para persistir.
Si está tratando de evitar que la gente se autentique mediante la fuerza bruta, un sistema de aceleración como el Gumbo sugerido probablemente funcione mejor. Hará que los ataques de fuerza bruta no interesen al atacante mientras minimiza el impacto para usuarios legítimos en circunstancias normales o incluso mientras se está produciendo un ataque. Sugeriría contar solo los intentos infructuosos de IP en memcached o similar, y si alguna vez te conviertes en el objetivo de un ataque de fuerza bruta extremadamente distribuido, siempre puedes optar por comenzar a hacer un seguimiento de los intentos por nombre de usuario, suponiendo que los atacantes de hecho, probando el mismo nombre de usuario a menudo. Siempre que el intento no esté extremadamente distribuido, ya que aún proviene de una cantidad contable de direcciones IP, el código inicial de IP debería mantener a los atacantes fuera de manera adecuada.
La clave para evitar problemas con visitantes de países con un número limitado de direcciones IP es no hacer que sus umbrales sean demasiado estrictos; Si no recibes múltiples intentos en un par de segundos, probablemente no tengas mucho de qué preocuparte. scripts de fuerza bruta. Si le preocupa más la posibilidad de que las personas intenten descifrar las contraseñas de otros usuarios de forma manual, puede establecer límites más amplios para los intentos fallidos de inicio de sesión por nombre de usuario.
Otra sugerencia, que no responde a su pregunta pero está relacionada de alguna manera, es imponer un cierto nivel de seguridad de contraseña a los usuarios finales. No me exageraría si requiriera una contraseña de mayúsculas, al menos x caracteres, sin diccionario, etc., porque no quiere molestar demasiado a las personas cuando aún no se han registrado, pero el simple hecho de impedir que las personas usen su nombre de usuario como contraseña debería ser muy útil para proteger su servicio y los usuarios contra los más simples (adivinen por qué los llaman fuerza bruta;) de ataques.
Jeff Atwood mencionó otro enfoque: en lugar de bloquear una cuenta después de una serie de intentos, aumente el tiempo hasta que se permita otro intento de inicio de sesión:
1st failed login no delay
2nd failed login 2 sec delay
3rd failed login 4 sec delay
4th failed login 8 sec delay
5th failed login 16 sec delay
Eso reduciría el riesgo de que se abuse de esta medida de protección para los ataques de denegación de servicio.