Prevención de ataques de diccionario en una aplicación web

Question

¿Cuál es la mejor manera de evitar un ataque de diccionario? He pensado varias implementaciones, pero todas parecen tener algún defecto:

1. Bloquea a un usuario después de X intentos fallidos de inicio de sesión. Problema: fácil de convertir en un ataque de denegación de servicio, bloqueando a muchos usuarios en un corto período de tiempo.
2. Aumente de forma incremental el tiempo de respuesta por intento de inicio de sesión fallido en un nombre de usuario. Problema: los ataques de diccionario pueden usar la misma contraseña pero diferentes nombres de usuario.
3. Aumente de forma incremental el tiempo de respuesta por intento fallido de inicio de sesión desde una dirección IP. Problema: fácil de evitar falsificando la dirección IP.
4. Aumente de forma incremental el tiempo de respuesta por intento de inicio de sesión fallido dentro de una sesión. Problema: es fácil moverse creando un ataque de diccionario que activa una nueva sesión en cada intento.

Answer 1

Me gusta mucho el sistema de fuerza anti-bruta de gmail. Se basa en el "calor" que un usuario puede acumular, una vez que el usuario se ha sobrecalentado, se le solicita un captcha. Puede realizar un seguimiento del calor utilizando una base de datos sql, o usando redis incr. El calor se asigna a una dirección IP. Es 100% imposible "falsificar" una conexión TCP a través de Internet debido a three-way-handshake, sin embargo, los servidores proxy son abundantes y las direcciones IP son muy económicas. Los servidores proxy se usan comúnmente para enviar spam, puede marcar blacklist y solicitar un captcha automáticamente.

Cada acción incorrecta contra su sistema actualizará la tabla de calor. Por ejemplo, un inicio de sesión fallido acumulará un 35% de calor. Una vez que el nivel de calor es mayor o igual al 100%, el usuario se ve obligado a resolver un captcha. La resolución de un captcha "enfriará" esa dirección IP. La tabla de calor podría contener una columna de marca de tiempo configurada en la hora actual de la actualización. Después de 24 horas más o menos el calor puede volver a 0.

reCaptcha es el captcha más seguro que puede usar.

Answer 2

Quizás necesite implementar CAPTCHA en sus formularios web.

Answer 3

Existe una compensación eterna entre seguridad, disponibilidad y usabilidad, lo que significa que no hay una solución perfecta.

Una compensación decente, dependiendo de su situación, es usar la opción # 1 con un captcha. Bloquee la cuenta después de tres intentos fallidos, pero permita intentos de inicio de sesión posteriores si un captcha está resuelto correctamente.

Answer 4

Siempre he sido fanático de su opción 3: bloquear o estrangular a un cliente en función de su dirección IP. Las otras opciones son más problemas de los que merecen por las razones que ha indicado.

Suplantación de spoofing es posible una dirección IP, pero no derrota esta contramedida. Si quiere decir "spoofing" en el sentido técnico - falsificando el encabezado del paquete TCP - entonces el atacante no le hará mucho bien, porque incluso si adivinan la contraseña correcta, no recibirán la respuesta que así lo indique. Todavía podrían usar proxies, por supuesto, pero el número de proxies es limitado. Incluso si un atacante tiene 1,000 servidores proxy de trabajo a su disposición y permite 10 intentos por IP, hay 10,000 intentos. Si aplica alguna complejidad a la contraseña (como requerir una contraseña alfanumérica), esto no será suficiente para adivinar mucho.

Eso solo debería ser suficiente para detener a la mayoría de los kiddies de scripts.Si te enfrentas a un atacante más determinado, es probable que tengas que implementar algún tipo de supervisión en todo el sitio que detecte que se están realizando muchos intentos (por lo que probablemente haya un ataque) y que "se bloquee" de alguna manera, por ejemplo . mediante el uso de CAPTCHA. No soy partidario de usar CAPTCHAs todo el tiempo; son más molestia de lo que valen.

En última instancia, le corresponde al usuario elegir una contraseña segura (aunque puede ayudarlos). Si han elegido "Contraseña1" como su contraseña, entonces nada de lo que pueda hacer impedirá que un pirata informático entre en su cuenta.

Answer 5

También recomendaría usar la opción 3. Si bien no es tan buena contra un atacante con una gran cantidad de proxies (o una red de bots), sigo pensando que es la mejor respuesta para la mayoría de los sitios. (Gmail tiene diferentes amenazas por parte de la mayoría de los sitios para que necesita diferentes respuestas.)

Un ejemplo del mundo real:
Un gran juego en línea que yo estoy involucrado en un seguimiento de cuántos intentos fallidos de conexión vienen de todas las direcciones IP en los últimos 5 minutos. En el momento en que una dirección IP se acumula 5 intentos de inicio de sesión incorrectos (independientemente del número de intentos exitosos), esa dirección se bloquea durante 45 minutos.

Por qué esto funciona
Me senté y determinó que un hacker muy inteligente sería capaz de romper una cuenta con el diccionario de aproximadamente 1 de cada 100 intentos (probablemente mucho peor). Por lo tanto, en el peor de los casos, un atacante divide 1 cuenta cada 100 minutos (por dirección IP). Para las amenazas contra este sitio en particular, esto fue suficiente protección. Nuestras cuentas realmente no valen tanto. Debe determinar (para su sitio) cuánta protección necesita. Puede ampliar la ventana a 30 minutos si desea que sea 3 veces más larga si lo necesita.

Nota importante
Do no recuento de reposición (ya sea para la solución de 3 o el mapa de calor descrito anteriormente) al iniciar la sesión con éxito. Si lo hace, el atacante solo intentará hackear 3 cuentas, luego iniciará sesión exitosamente en alguna cuenta que ya controle (la suya o una cuenta ya comprometida) y nunca será acelerada.

Answer 6

Depende de lo que quiere decir con "prevenir".

Si no quiere que desperdicien su ancho de banda, la regulación, el bloqueo, etc. son opciones viables. Hay sobrecarga con tablas de calor: tienes que crear y mantener la lógica, almacenar y administrar los "mapas de calor", etc., etc. También he visto algunos sistemas basados ​​en la geolocalización de IP que arrojan un captcha o alteran su registro de perfil si un usuario intenta iniciar sesión desde una ip "distante" o "desconocida".

Si simplemente desea reducir masivamente la efectividad de los ataques de diccionario, use un salt además de hash de contraseña.

Answer 7

Puede rechazar contraseñas que contengan palabras de diccionario si está programando para una aplicación donde la seguridad es realmente importante. No tiene que permitir que QWERTY sea una contraseña válida.

Answer 8

Primero, evite que sus usuarios elijan contraseñas comunes. Agregue una "lista negra" a su base de datos y verifique contraseñas nuevas. Puede rellenarlo utilizando una de las muchas listas de contraseñas o palabras, como aquí:

http://securityoverride.org/infusions/pro_download_panel/download.php?did=66

En segundo lugar, considerar un bloqueo temporal.Si tiene una tabla de "Usuario", agregue las columnas "LastLoginAttemptedOn" y "FailedLoginAttempts". Actualice estos valores cada vez que el usuario intente iniciar sesión. Cuando el usuario inicie sesión correctamente, restablezca FailedLoginAttempts a 0. Cuando FailedLoginAttempts llegue a 4 (o lo que prefiera), no permita que el usuario intente iniciar sesión durante 5 minutos (nuevamente, su preferencia) de LastLoginAttemptedOn. No actualice esta columna hasta que esté permitido intentarlo para evitar el intento de 4 minutos para restablecer el temporizador. Restablecer FailedLoginAttempts a 0 cuando el temporizador se restablece para que tengan varios intentos más.