security - password - ¿Cuál es la mejor contramedida de fuerza bruta distribuida?

brute force traductor (17)

¿Qué pasa si se requiere una contraseña de un solo uso antes de ingresar su contraseña normal? Eso haría muy obvio que alguien estaba atacando antes de que tuvieran muchas oportunidades de adivinar la contraseña principal.
Mantenga un conteo global / tasa de fallas de inicio de sesión - este es el indicador de un ataque - durante un ataque sea más estricto sobre las fallas de inicio de sesión, por ejemplo, prohibir las direcciones IP más rápidamente.

Primero, un poco de historia: no es ningún secreto que estoy implementando un sistema auth + auth para CodeIgniter, y hasta ahora estoy ganando (por así decirlo). Pero me encontré con un desafío bastante no trivial (uno que la mayoría de las bibliotecas de auth fallan por completo, pero insisto en manejarlo adecuadamente): cómo lidiar inteligentemente con los ataques de fuerza bruta distribuidos y de nombre de usuario variable a gran escala .

Conozco todos los trucos habituales:

Limitar el número de intentos fallidos por IP / host y denegar el acceso de los delincuentes (por ejemplo, Fail2Ban), que ya no funciona, ya que las botnets se han vuelto más inteligentes
Combinando lo anterior con una lista negra de IPs / hosts "malos" conocidos (por ejemplo, DenyHosts) - que se basa en botnets que caen en el # 1, que cada vez más no lo hacen
Las listas blancas de IP / host se combinan con la autenticación tradicional (lamentablemente inútil con usuarios dinámicos de IP y la alta rotación en la mayoría de los sitios web)
Estableciendo un límite para todo el sitio en # intentos fallidos dentro de un período de N minutos / hora, y estrangulando (suspendiendo) todos los intentos de inicio de sesión durante varios minutos / horas (con el problema de que el ataque DoS se convierte en juego de botnet)
Fichas digitales obligatorias (certificados de clave pública) o tokens de hardware RSA para todos los usuarios sin opción de inicio de sesión / contraseña (sin duda una solución sólida, pero solo práctica para servicios dedicados cerrados)
Implementados esquemas de contraseñas ultrafuertes (por ej.,> 25 caracteres sin sentido con símbolos; de nuevo, demasiado poco prácticos para usuarios ocasionales)
Y, por último, CAPTCHA (que podría funcionar en la mayoría de los casos, pero son molestos para los usuarios y prácticamente inútiles contra un atacante decidido e ingenioso )

Ahora, estas son solo las ideas teóricamente viables. Hay muchas ideas basura que hacen que el sitio se abra de par en par (por ejemplo, para ataques triviales de DoS). Lo que quiero es algo mejor. Y por mejor, quiero decir:

Tiene que ser seguro (+) contra DoS y ataques de fuerza bruta, y no introducir nuevas vulnerabilidades que puedan permitir que un robot un poco más sigiloso continúe operando bajo el radar.
Tiene que ser automatizado. Si se requiere que un operador humano verifique cada inicio de sesión o monitoree actividad sospechosa, no funcionará en un escenario del mundo real
Tiene que ser factible para el uso general de la web (es decir, alta rotación, alto volumen y registro abierto que puede ser realizado por no programadores)
No puede impedir la experiencia del usuario hasta el punto en que los usuarios casuales se molestarán o frustrarán (y posiblemente abandonen el sitio)
No puede involucrar gatitos, a menos que sean realmente gatitos seguros

(+) Por ''seguro'', me refiero al menos tan seguro como la capacidad de un usuario paranoico de mantener su contraseña en secreto

Entonces, ¡vamos a escucharlo! ¿Cómo lo harías ? ¿Conoces alguna de las mejores prácticas que no he mencionado (oh, por favor di que sí)? Admito que tengo una idea propia (combinando ideas de 3 y 4), pero dejaré que los verdaderos expertos hablen antes de avergonzarme ;-)

Algunos pasos simples:

Ponga en lista negra ciertos nombres de usuario comunes, y úselos como un honeypot. Administrador, invitado, etc. No permita que nadie cree cuentas con estos nombres, de modo que si alguien intenta iniciar sesión, sabe que alguien está haciendo algo que no debería.

Asegúrese de que cualquier persona que tenga poder real en el sitio tenga una contraseña segura. Exige que los administradores / moderadores tengan contraseñas más largas con una combinación de letras, números y símbolos. Rechace contraseñas triviales simples de los usuarios habituales con una explicación.

Una de las cosas más simples que puede hacer es decirle a las personas cuando alguien intentó ingresar a su cuenta, y darles un enlace para reportar el incidente si no fueran ellos. Un mensaje simple cuando inician sesión como "Alguien intentó ingresar a su cuenta a las 4:20 AM del miércoles, bla, bla. Haga clic aquí si este no era usted". Te permite mantener algunas estadísticas sobre ataques. Puede intensificar las medidas de monitoreo y seguridad si ve que hay un aumento repentino en los accesos fraudulentos.

Anteriormente había respondido una pregunta muy similar en Cómo puedo acelerar los intentos de inicio de sesión de usuario en PHP . Reitero la solución propuesta aquí, ya que creo que muchos de ustedes la encontrarán informativa y útil para ver algún código real. Tenga en cuenta que el uso de un CAPTCHA podría no ser la mejor solución debido a los algoritmos cada vez más precisos que se utilizan en los busters CAPTCHA hoy en día:

No se puede evitar simplemente los ataques DoS encadenando la aceleración a una única IP o nombre de usuario. Diablos, ni siquiera puedes evitar intentos de inicio de sesión rápidos usando este método.

¿Por qué? Debido a que el ataque puede abarcar múltiples IP y cuentas de usuario por el simple hecho de eludir sus intentos de aceleración.

He visto publicado en otro lugar que, idealmente, debería hacer un seguimiento de todos los intentos de inicio de sesión fallidos en el sitio y asociarlos a una marca de tiempo, tal vez:

CREATE TABLE failed_logins( id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, username VARCHAR(16) NOT NULL, ip_address INT(11) UNSIGNED NOT NULL, attempted DATETIME NOT NULL ) engine=InnoDB charset=UTF8;

Decida ciertos retrasos en función de la cantidad total de inicios de sesión fallidos en un período de tiempo determinado. Debe basar esto en los datos estadísticos extraídos de la tabla failed_logins , ya que cambiarán con el tiempo según la cantidad de usuarios y cuántos de ellos pueden recuperar (y escribir) su contraseña.

10 failed attempts = 1 second 20 failed attempts = 2 seconds 30 failed attempts = reCaptcha

Consulte la tabla en cada intento fallido de inicio de sesión para encontrar el número de inicios de sesión fallidos durante un período de tiempo determinado, digamos 15 minutos:

SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

Si el número de intentos durante el período de tiempo dado supera su límite, aplique la limitación o fuerce a todos los usuarios a usar un captcha (es decir, volver a capturar) hasta que el número de intentos fallidos durante el período de tiempo determinado sea menor que el umbral.

// array of throttling $throttle = array(10 => 1, 20 => 2, 30 => ''recaptcha''); // assume query result of $sql is stored in $row $sql = ''SELECT MAX(attempted) AS attempted FROM failed_logins''; $latest_attempt = (int) date(''U'', strtotime($row[''attempted''])); // get the number of failed attempts $sql = ''SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)''; // assume the number of failed attempts was stored in $failed_attempts krsort($throttle); foreach ($throttle as $attempts => $delay) { if ($failed_attempts > $attempts) { // we need to throttle based on delay if (is_numeric($delay)) { $remaining_delay = time() - $latest_attempt - $delay; // output remaining delay echo ''You must wait '' . $remaining_delay . '' seconds before your next login attempt''; } else { // code to display recaptcha on login form goes here } break; } }

El uso de reCaptcha en un determinado umbral garantizaría que se minimice un ataque desde múltiples frentes y que los usuarios normales del sitio no experimenten un retraso significativo en los intentos de inicio de sesión fallidos legítimos. No puedo garantizar la prevención, ya que ya se ha ampliado que los CAPTCHA pueden ser eliminados. Existen soluciones alternativas, tal vez una variante de "Nombre este animal", que podría funcionar bastante bien como sustituto.

Dado que varias personas incluyeron CAPTCHA como un mecanismo humano alternativo, agregué una pregunta anterior de y enhebré la efectividad de CAPTCHA.

¿Ha sido craqueado / pirateado / OCR''d / derrotado / roto ReCaptcha?

El uso de CAPTCHA no limita las mejoras de su aceleración y otras sugerencias, pero creo que la cantidad de respuestas que incluyen CAPTCHA como una alternativa debería considerar los métodos basados en el ser humano disponibles para las personas que buscan romper la seguridad.

Descargo de responsabilidad: trabajo para una empresa de dos factores, pero no estoy aquí para conectarlo. Aquí hay algunas observaciones.

Las cookies pueden ser robadas con XSS y vulnerabilidades del navegador. Los usuarios generalmente cambian los navegadores o borran sus cookies.

Las direcciones IP de origen son simultáneamente dinámicamente variables y falsificables.

Captcha es útil, pero no autentica a un ser humano específico.

Se pueden combinar varios métodos con éxito, pero el buen gusto está ciertamente en orden.

La complejidad de las contraseñas es buena, todo lo que se base en contraseñas depende críticamente de que las contraseñas tengan suficiente entropía. En mi humilde opinión, una contraseña segura anotada en una ubicación física segura es mejor que una contraseña débil en la memoria. Las personas saben cómo evaluar la seguridad de los documentos en papel mucho mejor de lo que saben cómo calcular la entropía efectiva en el nombre de su perro cuando se usa como contraseña para tres sitios web diferentes. Considere darles a los usuarios la capacidad de imprimir una página grande o pequeña llena de códigos de acceso de uso únicos.

Las preguntas de seguridad como "¿cuál era tu mascota de la escuela secundaria?" Son en su mayoría otra forma pésima de "algo que sabes", la mayoría de ellas son fáciles de adivinar o directamente en el dominio público.

Como ha señalado, reducir los intentos de inicio de sesión fallidos es una solución de compromiso entre la prevención de ataques de fuerza bruta y la facilidad de hacer una cuenta. Las políticas de bloqueo agresivo pueden reflejar una falta de confianza en la entropía de contraseñas.

Personalmente, no veo el beneficio de imponer la caducidad de contraseñas en un sitio web de todos modos. El atacante obtiene su contraseña una vez, puede cambiarla y cumplir con esa política tan fácilmente como sea posible. Quizás uno de los beneficios es que el usuario puede notarlo antes si el atacante cambia la contraseña de la cuenta. Aún mejor sería si el usuario fuera notificado de alguna manera antes de que el atacante obtuviera acceso. Mensajes como "N intentos fallidos desde el último inicio de sesión" son útiles a este respecto.

La mejor seguridad proviene de un segundo factor de autenticación que está fuera de banda en relación con el primero. Como dijiste, los tokens de hardware en "algo que tienes" son geniales, pero muchos (no todos) tienen una sobrecarga de administración real asociada con su distribución. No conozco ninguna solución biométrica de "algo que seas" buena para los sitios web. Algunas soluciones de dos factores funcionan con proveedores de código abierto, algunas tienen PHP / Perl / Python SDK.

Hay tres factores de autenticación:

Un usuario sabe algo (es decir, una contraseña)
Un usuario tiene algo (es decir, un llavero)
Un usuario es algo (es decir, escaneo de retina)

Generalmente, los sitios web solo hacen cumplir la política n. ° 1. Incluso la mayoría de los bancos solo hacen cumplir la política 1. En cambio, confían en un enfoque de "sabe algo diferente" para la autenticación de dos factores. (IE: un usuario conoce su contraseña y el apellido de soltera de su madre.) Si puede, una forma de agregar un segundo factor de autenticación no es demasiado difícil.

Si puede generar alrededor de 256 caracteres de aleatoriedad, podría estructurar eso en una tabla de 16 × 16, y luego pedirle al usuario que le proporcione el valor en la tabla de la celda A-14, por ejemplo. Cuando un usuario se registra o cambia su contraseña, proporciónela y dígales que la imprima y la guarde.

La dificultad con este enfoque es que cuando un usuario olvida su contraseña, como lo hará, no puede ofrecer el estándar "responda esta pregunta y escriba una nueva contraseña", ya que también es vulnerable a la fuerza bruta. Además, no puede restablecerlo y enviarles uno nuevo por correo electrónico, ya que su correo electrónico también podría verse comprometido. (Ver: Makeuseof.com y su dominio robado).

Otra idea (que involucra gatitos), es lo que BOA llama SiteKey (creo que marcaron el nombre). En pocas palabras, le pide al usuario que cargue una imagen cuando se registran, y cuando intentan iniciar sesión, pídales que seleccionen su imagen de 8 o 15 (o más) aleatorias. Por lo tanto, si un usuario sube una imagen de su gatito, teóricamente solo ellos sabrán exactamente qué imagen es la suya entre todos los otros gatitos (o flores o lo que sea). La única vulnerabilidad real que tiene este enfoque es el ataque del hombre en el medio.

Sin embargo, una idea más (sin gatitos) es rastrear IPs con las que los usuarios acceden al sistema, y requerirles que realicen una autenticación adicional (captcha, elegir un gatito, elegir una clave de esta tabla) cuando inician sesión desde una dirección que no conocen antes Además, de forma similar a GMail, permite al usuario ver de dónde han iniciado sesión recientemente.

Editar, Nueva Idea:

Otra forma de validar los intentos de inicio de sesión es verificar si el usuario proviene de su página de inicio de sesión o no. No puede verificar las referencias, ya que pueden ser fácilmente falsificadas. Lo que necesita es establecer una clave en _SESSION var cuando el usuario vea la página de inicio de sesión, y luego verificar que esa clave exista cuando envíe su información de inicio de sesión. Si bot no se envía desde la página de inicio de sesión, no podrá iniciar sesión. También puede facilitar esto al incluir javascript en el proceso, ya sea al usarlo para establecer una cookie o al agregar información al formulario una vez que se haya cargado. O bien, puede dividir el formulario en dos presentaciones diferentes (es decir, el usuario ingresa su nombre de usuario, envía, luego en una nueva página ingresa su contraseña y vuelve a enviarla).

La clave, en este caso, es el aspecto más importante. Un método común para generarlos es una combinación de los datos del usuario, su IP y la hora en que se envió.

La primera respuesta que usualmente he escuchado al hacer esta pregunta es cambiar los puertos, pero olvídate de eso y solo inhabilita IPv4. Si solo permite clientes de redes IPv6, ya no orará por un simple escaneo de red y los atacantes recurrirán a búsquedas de DNS. No se ejecute en la misma dirección que su Apache (AAAA) / Sendmail (MX-> AAAA) / lo que le ha dado a todos (AAAA). Asegúrate de que tu zona no pueda ser compartida, espera a que tu zona sea descargada por cualquiera.

Si los bots encuentran que su servidor está configurando nuevos nombres de host, simplemente anteponga algunos galimatías a sus nombres de host, y cambie su dirección. Deje los nombres antiguos e incluso la configuración ** nombres de honeypot para que la red bot agote el tiempo de espera.

** Pon a prueba tus registros inversos (PTR) (en ip6.arpa) para ver si se pueden usar para concentrar en / 4 que tienen registros VS / 4 que no lo hacen. IE Típicamente ip6.arpa tendría ~ 32 "." S en una dirección, pero tratar con los últimos que faltan podría eludir los bloques de red que tienen registros VS otros que no. Si lleva eso más allá, es posible omitir grandes porciones del espacio de direcciones.

En el peor de los casos, los usuarios tendrán que configurar un túnel IPv6, no es como si tuvieran que llegar hasta una DMZ ... Aunque uno se pregunta por qué esa no es la primera opción.

También Kerberos es genial, pero en mi humilde opinión, LDAP falla (¿Qué es técnicamente incorrecto con NISPlus? He leído que Sun decidió que los usuarios querían LDAP y, debido a esto, descartaron NIS +). Kerberos funciona bien sin LDAP o NIS, solo tiene que gestionar usuarios host por host. El uso de Kerberos le proporciona una PKI fácil de usar, si no automatizada.

Mi más alta recomendación es simplemente asegurarme de mantener a los usuarios informados de los intentos de acceso incorrectos a sus cuentas. Los usuarios probablemente tomarán la fortaleza de su contraseña mucho más en serio si se les presenta evidencia de que alguien realmente intenta ingresar a su cuenta. .

De hecho, atrapé a alguien que pirateó la cuenta de myspace de mi hermano porque habían intentado acceder a la cuenta de Gmail que configuré para él y usé la función "restablecer mi contraseña por correo electrónico" ... que fue a mi bandeja de entrada.

No creo que haya una respuesta perfecta, pero me inclinaría a abordarla sobre la base de tratar de confundir a los robots si se detecta un ataque.

Fuera de mi mente:

Cambia a una pantalla de inicio de sesión alternativa. Tiene múltiples espacios en blanco de nombre de usuario y contraseña que realmente aparecen pero solo uno de ellos está en el lugar correcto. Los nombres de los campos son RANDOM - se envía una clave de sesión junto con la pantalla de inicio de sesión, el servidor puede averiguar qué campos son qué. Si tiene éxito o falla, se descarta, por lo que no puede intentar un ataque de repetición. Si rechaza la contraseña, obtiene una nueva ID de sesión.

Se supone que cualquier formulario enviado con datos en un campo incorrecto procede de un robot: el inicio de sesión falla, el período y esa IP se acelera. Asegúrese de que los nombres de campo aleatorios nunca coincidan con los nombres de campo de fiar, de modo que alguien que use algo que recuerde contraseñas no sea engañoso.

Luego, ¿qué tal un tipo diferente de captcha? Tienes una serie de preguntas que no causarán problemas para un humano. Sin embargo, NO son aleatorios. Cuando comienza el ataque, todos reciben la pregunta n. ° 1. Después de una hora, la pregunta n. ° 1 se descarta, nunca se volverá a usar y todos recibirán la pregunta n. ° 2 y así sucesivamente.

El atacante no puede sondear para descargar la base de datos para ponerla en su robot debido a la naturaleza desechable de las preguntas. Tiene que enviar nuevas instrucciones a su botnet en una hora para tener la capacidad de hacer cualquier cosa.

No importa cuán bueno sea su sistema, fallará en un ataque lo suficientemente prolongado. Aquí hay algunas buenas ideas sobre cómo extender la duración de una contraseña. (Personalmente, me gusta la idea de limitar de forma exponencial la tasa de intentos por usuario y por dirección IP.) Pero no importa lo que ocurra, tendrá que respaldarlo con algunas reglas de contraseña.

Te animo a que averigües qué tan rápido se puede descifrar una contraseña y que los usuarios la cambien el doble de veces. Espero que esto ayude.

Editar: Si esperas un montón de atacantes perezosos, necesitar un poco de CAPTCHA después de múltiples intentos fallidos es bueno: sube un poco la barra. Si le preocupan muchos atacantes inteligentes, contrate a un asesor de seguridad. ;)

Para resumir el esquema de Jens en un diagrama de transición pseudoestado / base de reglas:

usuario + contraseña -> entrada
usuario +! contraseña -> denegado
usuario + known_IP (usuario) -> puerta de entrada, // never throttle
usuario + unknown_IP (usuario) -> catflap
(#denied> n) a través de catflaps (sitio) -> throttle catflaps (sitio) // slow the bots
catflap + throttle + password + captcha -> entry // humans still welcome
catflap + throttle + password +! captcha -> denied // a correct guess from a bot

Observaciones:

Nunca estrangule la puerta delantera. La policía estatal de Elbon tiene su computadora, en su casa, pero no pueden interrogarlo. La fuerza bruta es un enfoque viable desde su computadora.
Si proporciona un "¿Olvidó su contraseña?" enlace, entonces su cuenta de correo electrónico se convierte en parte de la superficie de ataque.

Estas observaciones cubren un tipo diferente de ataque a los que estás tratando de contrarrestar.

Parece que estás tratando de defenderte contra la fuerza bruta distribuida lentamente . No hay mucho que puedas hacer al respecto. Estamos utilizando una PKI y no hay inicios de sesión con contraseña. Ayuda, pero si sus clientes tienen la oportunidad de trabajar en estaciones de trabajo de vez en cuando, esto no es muy aplicable.

Si entiendo correctamente el MO de los ataques de fuerza bruta, uno o más nombres de usuario se prueban de forma continua.

Hay dos sugerencias que no creo haber visto todavía aquí:

Siempre pensé que la práctica estándar era tener un pequeño retraso (un segundo más o menos) después de cada inicio de sesión incorrecto para cada usuario. Esto disuade a la fuerza bruta, pero no sé por cuánto tiempo un retraso de un segundo mantendría a raya un ataque de diccionario. (diccionario de 10,000 palabras == 10,000 segundos == alrededor de 3 horas. Hmm. No lo suficiente).
en lugar de una ralentización en todo el sitio, ¿por qué no un acelerador de nombre de usuario? El acelerador se vuelve cada vez más duro con cada intento equivocado (hasta un límite, supongo que el usuario real aún puede iniciar sesión)

Editar : en respuesta a los comentarios sobre un acelerador de nombre de usuario: este es un acelerador específico de nombre de usuario sin tener en cuenta la fuente del ataque.

Si el nombre de usuario es acelerado, incluso un ataque de nombre de usuario coordinado (IP múltiple, conjetura individual por IP, mismo nombre de usuario) sería atrapado. Los nombres de usuario individuales están protegidos por el acelerador, incluso si los atacantes son libres de probar otro usuario / pase durante el tiempo de espera.

Desde el punto de vista de los atacantes, durante el tiempo de espera, es posible que adivine por primera vez 100 contraseñas y descubra rápidamente una contraseña incorrecta por cuenta. Es posible que solo pueda hacer una aproximación de 50 segundos para el mismo período de tiempo.

Desde el punto de vista de una cuenta de usuario, aún se necesita el mismo número promedio de intentos para descifrar la contraseña, incluso si las suposiciones provienen de múltiples fuentes.

Para los atacantes, en el mejor de los casos, será el mismo esfuerzo romper 100 cuentas como lo haría con 1 cuenta, pero como no está estrangulando en todo el sitio, puede aumentar el acelerador rápidamente.

Refinamientos adicionales:

detectar direcciones IP que adivinan varias cuentas: 408 Tiempo de espera de solicitud
detectar direcciones IP que adivinan la misma cuenta: 408 Tiempo de espera de solicitud después de un número grande (digamos 100) de conjeturas.

Ideas de UI (pueden no ser adecuadas en este contexto), que también pueden refinar lo anterior:

Si tiene el control de la configuración de la contraseña, mostrarle al usuario qué tan fuerte es su contraseña lo anima a elegir una mejor.
si tiene el control de la página de inicio de sesión, después de un número pequeño (digamos 10) de conjeturas de un único nombre de usuario, ofrezca un CAPTCHA.

También puede acelerar según la fuerza de la contraseña de un usuario.

Cuando un usuario se registra o cambia su contraseña, calcula una clasificación de resistencia para su contraseña, por ejemplo, entre 1 y 10.

Algo como "contraseña" obtiene un puntaje de 1, mientras que "c6eqapRepe7et * Awr @ ch" puede obtener un puntaje de 9 o 10 y cuanto mayor sea el puntaje, más tiempo tardará en acelerarse.

Tengo que preguntar si ha realizado un análisis de costo-beneficio de este problema; parece que estás tratando de protegerte de un atacante que tiene suficiente presencia en la web para adivinar una cantidad de contraseñas, enviando entre 3 y 5 solicitudes por IP (ya que has descartado la limitación de IP). ¿Cuánto (aproximadamente) costaría ese tipo de ataque? ¿Es más caro que el valor de las cuentas que intentas proteger? ¿Cuántas botnets gigantescos quieren lo que tienes?

La respuesta podría ser no, pero si lo es, espero que esté recibiendo ayuda de algún tipo de profesional de seguridad; la habilidad de programación (y la puntuación de ) no se correlacionan fuertemente con los conocimientos de seguridad.

Un poco tarde aquí, pero estaba pensando, asumiendo un caso difícil: el atacante usa una gran cantidad de direcciones IP aleatorias, nombres de usuario aleatorios y una contraseña aleatoria seleccionada de, digamos, una lista de los 10 000 más populares.

Una cosa que podría hacer, especialmente si el sistema parece estar siendo atacado, hay muchos intentos incorrectos de contraseña en el sistema y especialmente si la contraseña es de baja entropía es hacer una pregunta secundaria como cuáles son los nombres de pila de sus padres, por ejemplo . Si un atacante alcanza un millón de cuentas probando la contraseña ''contraseña1'', hay una gran posibilidad de que obtenga mucho, pero sus probabilidades de obtener los nombres correctos reducirían los éxitos dramáticamente.

Muy bien, suficiente estancamiento; esto es lo que se me ocurrió hasta ahora

(Lo siento, larga publicación por delante. Sé valiente, amigo, el viaje valdrá la pena)

Combina los métodos 3 y 4 de la publicación original en una especie de lista blanca "difusa" o dinámica, y luego, y aquí está el truco, no bloquea las IP no incluidas en la lista blanca, limitándolas al infierno y viceversa .

Tenga en cuenta que esta medida solo pretende frustrar este tipo de ataque muy específico. En la práctica, por supuesto, funcionaría en combinación con otros enfoques de mejores prácticas para auth: aceleración de nombre de usuario fijo, aceleración por IP, política de contraseña sólida implementada por código, inicio de sesión de cookies sin estrangulamiento, hash todos los equivalentes de contraseña antes de guardarlos, nunca usando preguntas de seguridad, etc.

Supuestos sobre el escenario de ataque

Si un atacante tiene como objetivo nombres de usuario variables, nuestro límite de nombre de usuario no se activa. Si el atacante está utilizando una botnet o tiene acceso a un amplio rango de IP, nuestra regulación de IP no tiene ningún poder. Si el atacante ha raspado previamente nuestra lista de usuarios (generalmente posible en servicios web de registro abierto), no podemos detectar un ataque continuo basado en el número de errores de "usuario no encontrado". Y si aplicamos un límite restrictivo para todo el sistema (todos los nombres de usuario, todos los IP), cualquier ataque de este tipo causará todo nuestro sitio durante la duración del ataque más el período de aceleración.

Entonces tenemos que hacer otra cosa.

La primera parte de la contramedida: lista blanca

De lo que podemos estar bastante seguros es de que el atacante no puede detectar y falsificar dinámicamente las direcciones IP de varios miles de nuestros usuarios (+). Lo que hace factibles las listas blancas . En otras palabras: para cada usuario, almacenamos una lista de las direcciones IP (hash) desde donde el usuario ha iniciado sesión (recientemente).

Por lo tanto, nuestro esquema de listas blancas funcionará como una ''puerta de entrada'' cerrada, donde un usuario debe estar conectado desde una de sus ''buenas'' IP reconocidas para poder iniciar sesión. Un ataque de fuerza bruta contra esta "puerta principal" sería prácticamente imposible (+).

(+) a menos que el atacante sea "propietario" del servidor, de todas las casillas de nuestros usuarios o de la conexión en sí, y en esos casos, ya no tenemos un problema de ''autenticación'', tenemos una verdadera franquicia del tamaño de una franquicia. -plug FUBAR situación

La segunda parte de la contramedida: regulación de todo el sistema de direcciones IP no reconocidas

Para hacer que una lista blanca funcione para un servicio web de registro abierto, donde los usuarios cambian las computadoras con frecuencia y / o se conectan desde direcciones IP dinámicas, necesitamos mantener abierta una ''puerta de gato'' para los usuarios que se conectan desde direcciones IP no reconocidas. El truco está en diseñar esa puerta para que los botnets se atasquen, y los usuarios legítimos se molesten lo menos posible .

En mi esquema, esto se logra estableciendo un número máximo muy restrictivo de intentos fallidos de inicio de sesión por IP no aprobadas durante, por ejemplo, un período de 3 horas (puede ser más prudente usar un período más corto o más largo según el tipo de servicio), y haciendo que esa restricción sea global , es decir. para todas las cuentas de usuario.

Incluso una fuerza bruta lenta (1-2 minutos entre intentos) sería detectada y frustrada de forma rápida y efectiva con este método. Por supuesto, una fuerza bruta realmente lenta podría pasar inadvertida, pero velocidades demasiado lentas vencerán el propósito del ataque de fuerza bruta.

Lo que espero lograr con este mecanismo de aceleración es que, si se alcanza el límite máximo, nuestra "puerta de gato" cierra de golpe por un momento, pero nuestra puerta de entrada permanece abierta para que los usuarios legítimos se conecten por los medios habituales:

Al conectarse desde una de sus direcciones IP reconocidas
O mediante el uso de una cookie de inicio de sesión persistente (desde cualquier lugar)

Los únicos usuarios legítimos que se verían afectados durante un ataque, es decir. mientras se activaba la aceleración, serían los usuarios sin cookies de inicio de sesión persistentes que iniciaban sesión desde una ubicación desconocida o con una dirección IP dinámica. Esos usuarios no podrían iniciar sesión hasta que el estrangulamiento se haya disipado (lo que podría tomar un tiempo, si el atacante mantuvo su botnet funcionando a pesar del estrangulamiento).

Para permitir que este pequeño subconjunto de usuarios se escurriera a través de la puerta de gato sellada de otro modo, incluso cuando los bots todavía estaban martillando, emplearía un formulario de "copia de seguridad" con un CAPTCHA. De modo que, cuando muestre el mensaje "Lo sentimos, pero no puede iniciar sesión desde esta dirección IP en este momento", 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 límite de todo el sitio. De esta forma, SI son humanos Y conocen la contraseña correcta (y pueden leer CAPTCHA), nunca se les negará el servicio, incluso si se conectan desde un host desconocido y no usan la cookie de autenticación automática.

Ah, y solo para aclarar: dado que considero que los CAPTCHA son en general malvados, la opción de inicio de sesión de "copia de seguridad" solo aparecería mientras la regulación estuviera activa .

No se puede negar que un ataque sostenido como ese constituiría todavía una forma de ataque DoS, pero con el sistema descrito implementado, solo afectaría lo que sospecho que es un pequeño subconjunto de usuarios, es decir, personas que no usan el sistema. "recuérdame" cookie Y sucede que está ingresando mientras ocurre un ataque Y no está iniciando sesión desde ninguna de sus direcciones IP habituales Y que no puede leer CAPTCHA. Solo aquellos que pueden decir NO a TODOS esos criterios, específicamente bots y personas realmente desafortunadas , serán rechazados durante un ataque de bot.

EDITAR: En realidad, pensé en una forma de permitir que incluso los usuarios desafiados por CAPTCHA pasen durante un ''bloqueo'': en lugar de, o como complemento del inicio de sesión CAPTCHA de respaldo, brinde al usuario la opción de tener un único uso , código de bloqueo específico del usuario enviado a su correo electrónico, que luego puede utilizar para eludir la regulación. Esto definitivamente cruza mi umbral de "molestia", pero como solo se utiliza como último recurso para un pequeño subconjunto de usuarios, y dado que aún supera el bloqueo de su cuenta, sería aceptable.

(Además, tenga en cuenta que nada de esto sucede si el ataque es menos sofisticado que la desagradable versión distribuida que he descrito aquí. Si el ataque proviene de solo unas pocas direcciones IP o solo toca algunos nombres de usuario, se frustrará mucho antes y sin consecuencias en todo el sitio)

Entonces, esa es la contramedida que implementaré en mi biblioteca de autenticación, una vez que esté convencido de que es sólida y que no hay una solución mucho más simple que me haya perdido. El hecho es que hay muchas maneras sutiles de hacer las cosas mal en materia de seguridad, y no estoy por encima de hacer suposiciones falsas o una lógica irremediablemente defectuosa. Por lo tanto, cualquier comentario, crítica y mejoras, sutilezas, etc. son muy apreciados.