security - riesgos - owasp top 10 2018 español pdf

Prevención de ataques de diccionario en una aplicación web (8)

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

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.
Incrementa de forma incrementada 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 nombres de usuario diferentes.
Aumente de forma incrementada el tiempo de respuesta por intento fallido de inicio de sesión desde una dirección IP. Problema: fácil de evitar mediante la suplantación de la dirección IP.
Incrementa de forma incrementada el tiempo de respuesta por intento de inicio de sesión fallido dentro de una sesión. Problema: fácil de solucionar creando un ataque de diccionario que active una nueva sesión en cada intento.

Depende de lo que quieras decir con "prevenir".

Si no desea que desperdicien su ancho de banda, la limitación, el bloqueo, etc. son opciones viables. Hay sobrecarga con las tablas de calor: tiene que crear y mantener la lógica, almacenar y administrar los "mapas de calor", etc. También he visto algunos sistemas basados en geolocalización ip que generan un captcha o alteran su registro. en el 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 hashes de contraseña.

En primer lugar, evite que los usuarios elijan contraseñas comunes. Agregue una "lista negra" a su base de datos y verifique las nuevas contraseñas contra ellos. 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, considere 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 de nuevo a 0. Cuando FailedLoginAttempts alcance 4 (o lo que prefiera), no permita que el usuario intente iniciar sesión durante 5 minutos ( una vez más, su preferencia) de LastLoginAttemptedOn. No actualice esta columna hasta que realmente tengan permiso para intentar evitar el intento de reinicio del temporizador 4 minutos después. Reinicie FailedLoginAttempts a 0 cuando el temporizador se reinicia para que tengan varios reintentos más.

Existe una eterna compensación entre seguridad, disponibilidad y facilidad de uso, 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 subsiguientes si se resuelve correctamente un captcha.

Me gusta mucho el sistema contra la fuerza 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 utilizando 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 al three-way-handshake ; sin embargo, los servidores proxy son abundantes y la dirección IP es muy barata. Los servidores proxy se utilizan comúnmente para enviar correo no deseado, puede consultar una blacklist y solicitar automáticamente un captcha.

Cada mala acción contra tu 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. Resolver un captcha "enfriará" esa dirección IP. La tabla de calor podría contener una columna de marca de tiempo que se establece en la hora actual en la actualización. Después de 24 horas aproximadamente, el calor puede volver a 0.

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

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

Siempre me ha gustado su opción 3: bloquear o limitar un cliente en función de su dirección IP. Las otras opciones son todas más problemáticas de lo que valen por las razones que ha indicado.

Es posible falsificar una dirección IP, pero no anula esta contramedida. Si te refieres a "suplantación de identidad" en el sentido técnico, forjando el encabezado del paquete TCP, entonces el atacante no servirá de mucho, porque incluso si adivinan la contraseña correcta, no recibirán la respuesta que se 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 a su disposición y usted permite 10 intentos por IP, eso es 10,000 intentos. Si aplica alguna complejidad de 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 niños de script. Si te enfrentas a un atacante más decidido, es probable que tengas que implementar algún tipo de monitoreo en todo el sitio que detecte que se están realizando muchos intentos (por lo que probablemente haya un ataque) y "se bloquea" de alguna manera, por ejemplo . mediante el uso de CAPTCHAs. No soy un fanático de usar CAPTCHAs todo el tiempo, solo son más molestos de lo que valen.

En última instancia, depende del usuario elegir una contraseña segura (aunque puede ayudarlo). Si han elegido "Contraseña1" como su contraseña, nada de lo que pueda hacer evitará que un pirata informático entre en su cuenta.

Tal vez necesite implementar CAPTCHA en sus formularios web.

También recomendaría usar la opción 3. Si bien no es tan bueno contra un atacante con un gran número de proxies (o una red de bot), todavía creo que es la mejor respuesta para la mayoría de los sitios. (Gmail tiene diferentes amenazas de la mayoría de los sitios, por lo que necesita respuestas diferentes).

Un ejemplo del mundo real:
Un gran juego en línea en el que participo hace un seguimiento de cuántos intentos de inicio de sesión fallidos provienen de cada dirección IP en los últimos 5 minutos. En el momento en que cualquier dirección IP acumula 5 intentos de inicio de sesión incorrectos (independientemente del número de intentos exitosos), esa dirección se bloquea durante 45 minutos.

Porque esto funciona
Me senté y decidí que un hacker altamente inteligente sería capaz de romper una cuenta con el diccionario aproximadamente 1 de cada 100 intentos (probablemente mucho peor). Por lo tanto, en el peor de los casos, un atacante tiene una cuenta de interrupción 1 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 mucho. Debe determinar (para su sitio) cuánta protección necesita. Podría extender la ventana a 30 minutos si quisiera que durara 3 veces más si lo necesitaba.

Nota IMPORTANTE
No reinicie los conteos (ya sea para la solución 3 o el mapa de calor descrito anteriormente) después de iniciar sesión correctamente. Si lo hace, el atacante solo intentará piratear 3 cuentas, luego ingresará con éxito a alguna cuenta que ya controla (la suya o una cuenta ya comprometida) y nunca se limitará.