security - todas - tipos de ataques de fuerza bruta

Prevención de Inicios de Fuerza Bruta en sitios web (13)

Como respuesta a los recientes secuestros de Twitter y la publicación de Jeff sobre ataques de diccionario , ¿cuál es la mejor manera de proteger su sitio web contra ataques de inicio de sesión de fuerza bruta?

La publicación de Jeff sugiere una demora cada vez mayor para cada intento de inicio de sesión, y una sugerencia en los comentarios es agregar un captcha después del segundo intento fallido.

Ambas parecen buenas ideas, pero ¿cómo sabes cuál es el "número de intento"? No puede confiar en una ID de sesión (porque un atacante podría cambiarla cada vez) o una dirección IP (mejor, pero vulnerable a botnets). Simplemente, al iniciar sesión con el nombre de usuario, con el método de demora, se puede bloquear a un usuario legítimo (o al menos hacer que el proceso de inicio de sesión sea muy lento para ellos).

¿Pensamientos? Sugerencias?

Para elaborar sobre la mejor práctica:

Lo que dijo krosenvold: registra num_failed_logins y last_failed_time en la tabla de usuarios (excepto cuando el usuario está suspendido), y una vez que el número de inicios de sesión fallidos alcanza un umbral, suspendes al usuario por 30 segundos o un minuto. Es la mejor práctica.

Ese método elimina eficazmente ataques de diccionario y fuerza bruta de una cuenta. Sin embargo, no evita que un atacante cambie de nombre de usuario, es decir. manteniendo la contraseña fija y probándola con una gran cantidad de nombres de usuario. Si su sitio tiene suficientes usuarios, ese tipo de ataque se puede mantener durante mucho tiempo antes de que se agote la cuenta de las cuentas no suspendidas. Con suerte, ejecutará este ataque desde una única IP (aunque no es probable, ya que las botnets se están convirtiendo en la herramienta de la operación actual) para que pueda detectar eso y bloquear la IP, pero si está distribuyendo el ataque ... Bueno, esa es otra pregunta (que acabo de publicar aquí, así que, por favor, échale un vistazo si no lo has hecho) .

Una cosa adicional para recordar acerca de la idea original es que, por supuesto, debe intentar dejar pasar al usuario legítimo, incluso mientras la cuenta está siendo atacada y suspendida, es decir, si puede diferenciar al usuario real y al bot.

Y PUEDES, al menos de dos maneras.

Si el usuario tiene una cookie de inicio de sesión persistente ("recuérdame"), déjalo pasar.
Cuando muestre el mensaje "Lo siento, su cuenta se ha suspendido debido a una gran cantidad de intentos fallidos de inicio de sesión", incluya un enlace que diga " inicio de sesión de copia de seguridad segura: SOLO HUMANOS (bots: sin mentir) ". Broma aparte, cuando hacen clic en ese enlace, les da un formulario de inicio de sesión autenticado reCAPTCHA que elude el estado de suspensión de la cuenta. De esta forma, SI son humanos Y conocen la contraseña correcta (y pueden leer CAPTCHA), nunca se verán afectados por los retrasos y su sitio será inmune a los ataques rápidos.

Único inconveniente: algunas personas (como las personas con problemas de visión) no pueden leer CAPTCHA, y PUEDEN aún verse afectadas por demoras molestas producidas por bots SI no están utilizando la función de autenticación automática.

Lo que NO es un inconveniente: que la cookie de autenticación no tenga una medida de seguridad similar incorporada. ¿Por qué no es esto un inconveniente, preguntas? Porque, siempre que lo haya implementado sabiamente, el token seguro (la contraseña equivalente) en su cookie de inicio de sesión es el doble de bits (por ejemplo, ¡haga diez veces más bits!) Que su contraseña, por lo que es una fuerza bruta efectivamente no es un problema . Pero si eres realmente paranoico, configura un retraso de un segundo en la función de autologin también, solo por si acaso.

Al igual que la mayoría de los bancos, bloquee el nombre de usuario / cuenta después de las fallas de inicio de sesión de X. Pero no sería tan estricto como un banco en el que debe llamar para desbloquear su cuenta. Solo haría un bloqueo temporal de 1 a 5 minutos. A menos que, por supuesto, la aplicación web sea tan sensible a los datos como un banco. :)

Creo que deberías iniciar sesión con el nombre de usuario. Esta es la única constante (cualquier otra cosa puede ser falsificada). Y sí, podría bloquear a un usuario legítimo por un día. Pero si debo elegir entre una cuenta pirateada y una cerrada (por un día), definitivamente elijo la cerradura.

Por cierto, después de un tercer intento fallido (dentro de un tiempo determinado) puede bloquear la cuenta y enviar un correo electrónico de liberación al propietario. El correo contiene un enlace para desbloquear la cuenta. Esta es una ligera carga para el usuario, pero el cracker está bloqueado. Y si incluso la cuenta de correo electrónico está pirateada, podría establecer un límite en el número de desbloqueos por día.

Debería implementar un caché en la aplicación no asociada con su base de datos back-end para este propósito.

En primer lugar, demorar solo los nombres de usuario legítimos hace que "abandones" en masa tu base de clientes válida, lo que puede ser un problema incluso si el nombre de usuario no es un secreto bien guardado.

En segundo lugar, dependiendo de su aplicación, puede ser un poco más inteligente con las medidas de demora específicas de la aplicación de lo que podría desear con el almacenamiento de los datos en un DB.

Es resistente a los intentos de alta velocidad que derramarían una condición de DOS en tu back-end db.

Finalmente, es aceptable tomar algunas decisiones basadas en IP ... Si ve intentos individuales de un IP, es probable que se trate de un error honesto frente a múltiples direcciones IP de Dios sabe cuántos sistemas es posible que desee tomar otras precauciones o notificar al usuario final de actividad sombría.

Sus verdaderas federaciones proxy grandes pueden tener números masivos de direcciones IP reservadas para su uso, pero la mayoría hace un esfuerzo razonable para mantener su dirección de origen durante un período de tiempo para fines heredados ya que algunos sitios tienen un hábito de vincular datos de cookies a IP.

En mi opinión, hay varias posibilidades, cada una teniendo ventajas y desventajas:

Forzar contraseñas seguras

Pro : evitará ataques de diccionario
Con : también evitará la popularidad, ya que la mayoría de los usuarios no pueden recordar contraseñas complejas, incluso si les explicas cómo recordarlas fácilmente. Por ejemplo, al recordar oraciones: "Compré 1 Apple por 5 centavos en el Mall" lleva a "Ib1Af5CitM".

Bloqueos después de varios intentos

Pro : ralentizará las pruebas automatizadas
Con : es fácil bloquear usuarios para terceros
Con : Hacerlos persistentes en una base de datos puede dar como resultado una gran cantidad de procesos de escritura en servicios tan enormes como Twitter o comparables.

Captchas

Pro : Impiden las pruebas automatizadas
Con : están consumiendo tiempo de computación
Con : "ralentizará" la experiencia del usuario
ENORME CON : NO son sin barreras

Verificaciones de conocimiento simples

Pro : evitará las pruebas automatizadas
Con : "Simple" está en el ojo del espectador.
Con : "ralentizará" la experiencia del usuario

Diferentes login y nombre de usuario

Pro : Esta es una técnica, que apenas se ve, pero a mis ojos es un buen comienzo para evitar ataques de fuerza bruta.
Con : Depende de la elección de los dos nombres por parte de los usuarios.

Use oraciones completas como contraseñas

Pro : aumenta el tamaño del espacio de posibilidades de búsqueda.
Pro : son más fáciles de recordar para la mayoría de los usuarios.
Con : depende de la elección de los usuarios.

Como puede ver, las soluciones "buenas" dependen de la elección del usuario, lo que nuevamente revela al usuario como el elemento más débil de la cadena.

¿Cualquier otra sugerencia?

Esta es una publicación vieja. Sin embargo, pensé en poner mis hallazgos aquí para que puedan ayudar a futuros desarrolladores.

Necesitamos prevenir el ataque de fuerza bruta para que el atacante no pueda recolectar el nombre de usuario y la contraseña del inicio de sesión de un sitio web. En muchos sistemas, tienen algunas direcciones abiertas que no requieren un token de autenticación o una clave API para la autorización. La mayoría de estas API son críticas. Por ejemplo; Las API de registro, inicio de sesión y olvido de contraseña a menudo son abiertas (es decir, no requieren una validación del token de autenticación). Debemos asegurarnos de que no se abuse de los servicios. Como dije antes, solo estoy exponiendo mis hallazgos mientras estudio sobre cómo podemos prevenir un ataque de fuerza bruta de manera eficiente.

La mayoría de las técnicas de prevención comunes ya se discuten en esta publicación. Me gustaría agregar mis preocupaciones sobre el bloqueo de cuentas y el bloqueo de direcciones IP. Creo que bloquear cuentas es una mala idea como técnica de prevención. Estoy poniendo algunos puntos aquí para apoyar mi causa.

El bloqueo de cuenta es malo

Un atacante puede causar una denegación de servicio (DoS) bloqueando un gran número de cuentas.
Como no puede bloquear una cuenta que no existe, solo se bloquearán los nombres de cuenta válidos. Un atacante podría usar este hecho para recolectar los nombres de usuario del sitio, dependiendo de las respuestas de error.
Un atacante puede causar una desviación bloqueando muchas cuentas e inundando el servicio de ayuda con llamadas de soporte.
Un atacante puede bloquear continuamente la misma cuenta, incluso segundos después de que un administrador la desbloquee, lo que desactiva efectivamente la cuenta.
El bloqueo de cuenta no es efectivo contra ataques lentos que solo prueban unas pocas contraseñas cada hora.
El bloqueo de cuenta no es efectivo contra ataques que prueban una contraseña contra una gran lista de nombres de usuario.
El bloqueo de cuenta no es efectivo si el atacante usa una lista combinada de nombre de usuario / contraseña y adivina correctamente los primeros intentos.
Las cuentas potentes, como las cuentas de administrador, a menudo omiten la política de bloqueo, pero estas son las cuentas más deseables para atacar. Algunos sistemas bloquean las cuentas de administrador solo en inicios de sesión basados en red.
Incluso una vez que bloquea una cuenta, el ataque puede continuar, consumiendo valiosos recursos humanos y de la computadora.
Considere, por ejemplo, un sitio de subastas en el que varios postores están peleando por el mismo artículo. Si el sitio web de la subasta impuso bloqueos de cuenta, un postor simplemente podría bloquear las cuentas de los demás en el último minuto de la subasta, lo que les impediría presentar ofertas ganadoras. Un atacante podría usar la misma técnica para bloquear transacciones financieras críticas o comunicaciones por correo electrónico.

El bloqueo de direcciones IP para una cuenta también es una mala idea

Otra solución es bloquear una dirección IP con múltiples inicios de sesión fallidos. El problema con esta solución es que podría bloquear inadvertidamente grupos grandes de usuarios al bloquear un servidor proxy utilizado por un ISP o una gran compañía. Otro problema es que muchas herramientas utilizan listas de proxy y envían solo unas pocas solicitudes de cada dirección IP antes de pasar a la siguiente. Utilizando listas de proxy abierto ampliamente disponibles en sitios web como http://tools.rosinstrument.com/proxy/ , un atacante podría eludir fácilmente cualquier mecanismo de bloqueo de IP. Como la mayoría de los sitios no se bloquean después de una sola contraseña fallida, un atacante puede usar dos o tres intentos por proxy. Un atacante con una lista de 1,000 proxies puede intentar 2,000 o 3,000 contraseñas sin ser bloqueado. Sin embargo, a pesar de las debilidades de este método, los sitios web que experimentan un gran número de ataques, sitios web para adultos en particular, eligen bloquear direcciones IP proxy.

Mi proposición

No bloqueando la cuenta. En su lugar, podríamos considerar agregar demoras intencionales desde el lado del servidor en los intentos de inicio / inicio de sesión por intentos incorrectos consecutivos.
Seguimiento de la ubicación del usuario según la dirección IP en los intentos de inicio de sesión, que es una técnica común utilizada por Google y Facebook. Google envía una OTP mientras que Facebook ofrece otros desafíos de seguridad como detectar a los amigos de los usuarios de las fotos.
Google re-captcha para la aplicación web, SafetyNet para Android y la técnica adecuada de certificación de aplicaciones móviles para iOS: en solicitudes de inicio de sesión o registro.
Cookie del dispositivo
Construir un sistema de monitoreo de llamadas API para detectar llamadas inusuales para un determinado punto final API.

Explicaciones de proposiciones

Retraso intencional en la respuesta

El retraso en la autenticación de contraseñas ralentiza significativamente al atacante, ya que el éxito del ataque depende del tiempo. Una solución fácil es inyectar pausas aleatorias al verificar una contraseña. Agregar incluso una pausa de unos segundos no molestará a la mayoría de los usuarios legítimos cuando inicien sesión en sus cuentas.

Tenga en cuenta que aunque agregar un retraso podría ralentizar un ataque de un solo subproceso, es menos efectivo si el atacante envía múltiples solicitudes de autenticación simultáneas.

Desafíos de seguridad

Esta técnica se puede describir como desafíos de seguridad adaptativos basados en las acciones realizadas por el usuario al usar el sistema antes. En el caso de un nuevo usuario, esta técnica podría arrojar desafíos de seguridad por defecto.

¿Podríamos plantearnos cuándo lanzaremos desafíos de seguridad? Hay varios puntos donde podemos.

Cuando el usuario está intentando iniciar sesión desde una ubicación donde antes no se encontraba cerca.
Intentos incorrectos de inicio de sesión.

¿Qué clase de desafío de seguridad podría enfrentar el usuario?

Si el usuario establece las preguntas de seguridad, podríamos considerar preguntarle al usuario las respuestas.
Para las aplicaciones como Whatsapp, Viber, etc., podríamos considerar tomar algunos nombres de contactos aleatorios de la agenda telefónica y pedirles que ingresen los números o viceversa.
Para los sistemas transaccionales, podríamos considerar preguntarle al usuario sobre las últimas transacciones y pagos.

Panel de monitoreo API

Para construir un panel de monitoreo para llamadas API.

Busque las condiciones que podrían indicar un ataque de fuerza bruta u otro abuso de cuenta en el panel de monitoreo de la API.
Muchos inicios de sesión fallidos desde la misma dirección IP.
Inicios de sesión con múltiples nombres de usuario de la misma dirección IP.
Ingresos para una sola cuenta proveniente de diferentes direcciones IP.
Uso excesivo y consumo de ancho de banda de un solo uso.
Intentos de inicio de sesión fallidos desde nombres de usuario o contraseñas secuenciales alfabéticamente.
Inicios de sesión con contraseñas sospechosas que los hackers usan comúnmente, como ownsyou (ownzyou), washere (wazhere), fanáticos, hacksyou, etc.

Para las cuentas internas del sistema, podríamos considerar permitir el inicio de sesión solo desde ciertas direcciones IP. Si el bloqueo de la cuenta debe estar en su lugar, en lugar de bloquear por completo una cuenta, colóquela en un modo de bloqueo con capacidades limitadas.

Aquí hay algunas buenas lecturas.

Muchos de los foros de mensajes en línea en los que me conecto en línea me dan 5 intentos de iniciar sesión en una cuenta, después de esos 5 intentos, la cuenta se bloquea durante una hora o quince minutos. Puede que no sea lindo, pero esto ciertamente ralentizaría un ataque de diccionario en una cuenta. Ahora nada detiene un ataque de diccionario contra varias cuentas al mismo tiempo. Es decir, intente 5 veces, cambie a una cuenta diferente, pruebe otras 5 veces, luego haga un círculo hacia atrás. Pero seguro que ralentiza el ataque.

¡La mejor defensa contra un ataque de diccionario es asegurarse de que las contraseñas no estén en el diccionario! Básicamente configura un tipo de política de contraseñas que verifica un diccionario con las letras y requiere un número o símbolo en la contraseña. Esta es probablemente la mejor defensa contra un ataque de diccionario.

Para el entorno .NET

Restricciones dinámicas de IP

La extensión de restricciones de IP dinámica para IIS proporciona a los profesionales de TI y Hosters un módulo configurable que ayuda a mitigar o bloquear ataques de denegación de servicio o descifrado de contraseñas mediante fuerza bruta al bloquear temporalmente las direcciones de protocolo de Internet (IP) de clientes HTTP que siguen un patrón que podría ser conducente a uno de esos ataques. Este módulo se puede configurar de manera que el análisis y el bloqueo se puedan realizar en el servidor web o en el nivel del sitio web.

Reduzca las posibilidades de un ataque de denegación de servicio al bloquear dinámicamente las solicitudes de direcciones IP maliciosas

Las restricciones dinámicas de IP para IIS le permite reducir las probabilidades de que su servidor web esté sujeto a un ataque de denegación de servicio inspeccionando la IP de origen de las solicitudes e identificando patrones que podrían indicar un ataque. Cuando se detecta un patrón de ataque, el módulo colocará la IP ofensiva en una lista de denegación temporal y evitará responder a las solicitudes durante un período de tiempo predeterminado.

Minimice las posibilidades de agrietamiento por fuerza bruta de las contraseñas de su servidor web

Las restricciones dinámicas de IP para IIS pueden detectar patrones de solicitudes que indican que se intenta decodificar las contraseñas del servidor web. El módulo colocará la IP infractora en una lista de servidores a los que se les denegó acceso durante un período de tiempo predeterminado. En situaciones donde la autenticación se hace contra un Servicio de Directorio Activo (ADS), el módulo puede mantener la disponibilidad del Servidor Web evitando tener que emitir desafíos de autenticación a ADS.

Caracteristicas

Integración perfecta en el Administrador de IIS 7.0.
Bloqueo dinámico de solicitudes de direcciones IP en función de uno de los siguientes criterios:
- El número de solicitudes simultáneas.
- El número de solicitudes durante un período de tiempo.
Compatibilidad con la lista de direcciones IP que pueden omitir el filtrado de restricción de IP dinámica.
El bloqueo de las solicitudes puede configurarse en el sitio web o en el nivel del servidor web.
Las acciones de denegación configurables permiten a los administradores de TI especificar qué respuesta se devolverá al cliente. El módulo admite los códigos de estado de retorno 403, 404 o el cierre de la conexión.
Soporte para direcciones IPv6.
Soporte para servidores web detrás de un proxy o firewall que pueden modificar la dirección IP del cliente.

http://www.iis.net/download/DynamicIPRestrictions

Podría agregar alguna forma de prueba CAPTCHA. Pero tenga en cuenta que la mayoría de ellos hace que el acceso sea más difícil para los ojos o para las personas con discapacidad auditiva. Una forma interesante de CAPTCHA es hacer una pregunta,

¿Cuál es la suma de 2 y 2?

Y si registra la última falla de inicio de sesión, puede omitir el CAPTCHA si es lo suficientemente antiguo. Solo haga la prueba CAPTCHA si la última falla fue durante los últimos 10 minutos.

Podrías hacer lo que hace Google. Que es después de un cierto número de intentos que tienen una captacha aparece. Luego de un par de veces con la captacha, los cierras por un par de minutos.

Publicación anterior, pero déjame publicar lo que tengo en este final de 2016. Espero que todavía pueda ayudar.

Es una manera sencilla, pero creo que es poderoso para evitar el ataque de inicio de sesión. Al menos siempre lo uso en cada web mía. No necesitamos CAPTCHA o cualquier otro complemento de terceros.

Cuando el usuario inicia sesión por primera vez. Creamos una sesión como

$_SESSION[''loginFail''] = 10; // any number you prefer

Si el acceso es exitoso, lo destruiremos y dejaremos que el usuario inicie sesión.

unset($_SESSION[''loginFail'']); // put it after create login session

Pero si el usuario falla, ya que normalmente les enviamos un mensaje de error, al mismo tiempo reducimos la sesión en 1:

$_SESSION[''loginFail'']-- ; // reduce 1 for every error

y si el usuario falla 10 veces, entonces los direccionaremos a otro sitio web o cualquier página web.

if (!isset($_SESSION[''loginFail''])) { if ($_SESSION[''login_fail''] < 1 ) { header(''Location:https://google.com/''); // or any web page exit(); } }

De esta manera, el usuario no puede abrir o ir a nuestra página de inicio de sesión, ya que se ha redirigido a otro sitio web.

Los usuarios tienen que cerrar el navegador (para destruir el inicio de sesión de sesiónFail que creamos), abrirlo de nuevo para ver nuestra página de inicio de sesión ''otra vez''.

¿Es útil?

Tiendo a estar de acuerdo con la mayoría de los otros comentarios:

Bloquear después de X intentos de contraseña fallidos
Recuento de intentos fallidos contra nombre de usuario
Opcionalmente, use CAPTCHA (por ejemplo, los intentos 1-2 son normales, los intentos 3-5 son CAPTCHA''d, intentos adicionales bloqueados durante 15 minutos).
Opcionalmente envíe un correo electrónico al propietario de la cuenta para eliminar el bloque

Lo que quería señalar es que debe tener mucho cuidado al forzar contraseñas "fuertes", ya que a menudo significa que se escribirán en un post-it en el escritorio / adjunto al monitor. Además, algunas políticas de contraseñas conducen a contraseñas más predecibles. Por ejemplo:

Si la contraseña no puede ser una contraseña usada anteriormente y debe incluir un número, existe una buena posibilidad de que sea una contraseña común con un número secuencial después de ella. Si tiene que cambiar su contraseña cada 6 meses, y una persona ha estado allí dos años, es probable que su contraseña sea algo como contraseña4 .

Digamos que lo restringe aún más: debe tener al menos 8 caracteres, no puede tener ninguna letra secuencial, debe tener una letra, un número y un carácter especial (esta es una política de contraseña real que muchos considerarían segura). ¿Intenta entrar en la cuenta de John Quincy Smith? ¿Sabes que nació el 6 de marzo? ¡Hay una buena probabilidad de que su contraseña sea algo así como jqs0306! (o tal vez jqs0306 ~ ).

Ahora bien, no estoy diciendo que permitir que los usuarios tengan la contraseña es una buena idea, simplemente no se engañe pensando que sus contraseñas "seguras" forzadas son seguras.

Creo que el período de bloqueo corto persistido por la base de datos para la cuenta determinada (1-5 minutos) es la única forma de manejar esto. Cada userid de userid en su base de datos contiene un timeOfLastFailedLogin y numberOfFailedAttempts . Cuando numbeOfFailedAttempts > X se numbeOfFailedAttempts > X durante algunos minutos.

Esto significa que está bloqueando el userid de userid en cuestión durante un tiempo, pero no permanentemente. También significa que está actualizando la base de datos para cada intento de inicio de sesión (a menos que esté bloqueado, por supuesto), lo que puede estar causando otros problemas.

Hay al menos un país completo con certificación NAT en Asia, por lo que las IP no se pueden usar para nada.