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

https://stackoverflow.com/questions/479233

20-08-2019
|

Pregunta

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

Conozco todos los trucos habituales:

Limitar el número de intentos fallidos por IP/host y negar el acceso a los infractores (p. ej.Fail2Ban) - que ya no funciona desde que las botnets se han vuelto más inteligentes
Combinando lo anterior con un lista negra de IP/hosts "malos" conocidos (p.ej.DenyHosts) - que se basa en botnets que ocupan el puesto número 1, lo cual cada vez más no hacen
Listas blancas de IP/host combinado con la autenticación tradicional (lamentablemente inútil con usuarios de IP dinámicos y la alta rotación en la mayoría de los sitios web)
Establecer un límite en todo el sitio en el número de intentos fallidos dentro de un período de N minutos/hora, y limitando (suspendiendo) todos los intentos de inicio de sesión posteriores durante un número de minutos/horas (con el problema de que atacarlo DoS se convierte en un juego de niños de botnet)
Obligatorio firmas digitales (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 lugar a dudas, una solución sólida, pero solo práctica para servicios cerrados y dedicados)
aplicado esquemas de contraseñas ultra fuertes (p.ej.>25 caracteres sin sentido con símbolos (nuevamente, demasiado poco práctico para usuarios ocasionales)
Y finalmente, CAPTCHA (que podrían funcionar en la mayoría de los casos, pero son molestos para los usuarios y prácticamente inútil contra un atacante decidido e ingenioso)

Ahora bien, estas son sólo las ideas teóricamente viables.Hay infinidad de ideas basura que hacen estallar el sitio (p. ej.hasta ataques DoS triviales).Lo que quiero es algo mejor.Y por mejor me refiero a:

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 astuto continúe operando bajo el radar.
Tiene que estar automatizado.Si requiere que un operador humano verifique cada inicio de sesión o supervise actividades sospechosas, no funcionará en un escenario del mundo real.
Tiene que ser factible para el uso generalizado de la web (es decir,alta rotación, alto volumen y registro abierto que pueden realizar personas que no son programadores)
No puede impedir la experiencia del usuario hasta el punto de que los usuarios ocasionales se molesten o se frustren (y potencialmente abandonen el sitio).
No puede involucrar gatitos, a menos que sean realmente muy seguro gatitos

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

Entonces, ¡escuchémoslo! Como lo harias?¿Conoce alguna práctica recomendada que no haya mencionado (oh, por favor, dígala)?Admito que tengo una idea propia (combinando las ideas de la 3 y la 4), pero dejaré que hablen los verdaderos expertos antes de avergonzarme ;-)

Solución

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

(lo siento, mucho tiempo por delante. Sé valiente, amigo, el viaje valdrá la pena)

Combinando 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, simplemente las estrangula al infierno y viceversa .

Tenga en cuenta que esta medida es solo destinada a 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 la autenticación: limitación de nombre de usuario fijo, limitación por IP, política de contraseña segura con código, inicio de sesión de cookie sin estrangulamiento, hash todos los equivalentes de contraseña antes de guardarlos, nunca utilizando preguntas de seguridad, etc.

Suposiciones sobre el escenario de ataque

Si un atacante apunta a nombres de usuario variables, nuestra limitación de nombre de usuario no se activa. Si el atacante está usando una botnet o tiene acceso a un amplio rango de IP, nuestra limitación de IP es impotente. Si el atacante ha eliminado previamente nuestra lista de usuarios (generalmente posible en servicios web de registro abierto), no podemos detectar un ataque continuo en función de la cantidad de errores de "usuario no encontrado". Y si aplicamos una restricción restrictiva en todo el sistema (todos los nombres de usuario, todas las IP), cualquier ataque de este tipo afectará a todo nuestro sitio durante la duración del ataque más el período de limitación.

Entonces necesitamos hacer algo más.

La primera parte de la contramedida: Lista blanca

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

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

(+) a menos que el atacante 'posea' el servidor, todos los cuadros de nuestros usuarios o la conexión en sí, y en esos casos, ya no tenemos un problema de 'autenticación', tenemos un verdadero tamaño de franquicia situación FUBAR de extracción automática

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

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

En mi esquema, esto se logra estableciendo un muy número máximo 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 inteligente usar un tiempo más corto o más corto). período más largo dependiendo del 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) se detectaría y frustraría de manera rápida y efectiva utilizando este método. Por supuesto, una fuerza bruta realmente lenta aún podría pasar desapercibida, pero velocidades demasiado lentas derrotan el propósito mismo 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' se cierra por un tiempo, pero nuestra puerta principal permanece abierta para usuarios legítimos que se conectan por los medios habituales:

Ya sea conectándose desde una de sus 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. whSi se activara la limitación, serían usuarios sin cookies de inicio de sesión persistentes que iniciaran sesión desde una ubicación desconocida o con una IP dinámica. Esos usuarios no podrán iniciar sesión hasta que la aceleración desaparezca (lo que podría llevar un tiempo, si el atacante mantiene su botnet funcionando a pesar de la aceleración).

Para permitir que este pequeño subconjunto de usuarios se filtre a través de la puerta para gatos sellada de otro modo, incluso cuando los bots aún la estaban golpeando, emplearía un formulario de inicio de sesión de 'respaldo' con un CAPTCHA. De modo que, cuando muestra & "; Lo siento, pero no puede iniciar sesión desde esta dirección IP en este momento &"; mensaje, incluya un enlace que diga " inicio de sesión de copia de seguridad segura - SOLO HUMANOS ( bots: no mentir ) " ;. Broma a un lado, cuando hacen clic en ese enlace, les dan un formulario de inicio de sesión autenticado reCAPTCHA que evita la limitación en todo el sitio. De esa manera, SI son humanos Y conocen el inicio de sesión + contraseña correctos (y pueden leer CAPTCHA), nunca se les negará el servicio, incluso si se conectan desde un host desconocido y no usan el cookie de inicio de sesión automático.

Ah, y solo para aclarar: dado que considero que los CAPTCHA son generalmente malos, la opción de inicio de sesión de "copia de seguridad" solo aparecería mientras la aceleración estaba activa .

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

EDIT: Actully, pensé en una manera de permitir que incluso los usuarios con CAPTCHA pasen durante un 'bloqueo': en lugar de, o como un El complemento para el inicio de sesión de CAPTCHA de respaldo le brinda al usuario la opción de recibir un código de bloqueo de un solo uso y específico del usuario en su correo electrónico, que luego puede usar para evitar el estrangulamiento. Esto definitivamente cruza mi umbral de 'molestia', pero dado que solo se usa 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 ninguno de esto ocurre si el ataque es menos sofisticado que la desagradable versión distribuida que he descrito aquí. Si el ataque proviene de unas pocas IP o solo golpea algunos nombres de usuario, se frustrarán mucho antes, y con no 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ólido 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 seguridad, y no estoy por encima de hacer suposiciones falsas o lógicas irremediablemente defectuosas. Así que por favor, todos y cada uno de los comentarios, críticas y mejoras, sutilezas, etc. son muy apreciados.

Otros consejos

Algunos pasos simples:

Incluya en la lista negra ciertos nombres de usuario comunes y utilícelos como un honeypot. Administrador, invitado, etc. No permita que nadie cree cuentas con estos nombres, por lo 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. Requerir que los administradores / moderadores tengan contraseñas más largas con una combinación de letras, números y símbolos. Rechace las contraseñas trivialmente simples de los usuarios habituales con una explicación.

Una de las cosas más simples que puede hacer es decirle a las personas cuándo alguien intentó iniciar sesión en su cuenta y darles un enlace para informar el incidente si no fueron ellos. Un mensaje simple cuando inician sesión como & Quot; Alguien intentó iniciar sesión en su cuenta a las 4:20 AM del miércoles, bla, bla. Haga clic aquí si no fue usted. & Quot; Le permite mantener algunas estadísticas sobre los ataques. Puede intensificar las medidas de monitoreo y seguridad si observa que hay un aumento repentino de accesos fraudulentos.

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

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

Siempre pensé que la práctica estándar era tener un breve retraso (aproximadamente un segundo) después de cada inicio de sesión incorrecto para cada usuario. Esto disuade la fuerza bruta, pero no sé cuánto tiempo un retraso de un segundo mantendría a raya un ataque de diccionario. (diccionario de 10,000 palabras == 10,000 segundos == aproximadamente 3 horas. Hmm. No es lo suficientemente bueno.)
en lugar de una desaceleración en todo el sitio, ¿por qué no un acelerador de nombre de usuario? El acelerador se vuelve cada vez más severo con cada intento incorrecto (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 se estrangula, se detectaría incluso un ataque de nombre de usuario coordinado (IP múltiple, respuesta simple por IP, mismo nombre de usuario). 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 puede ser capaz de adivinar por primera vez las 100 contraseñas y descubrir rápidamente una contraseña incorrecta por cuenta. Es posible que solo pueda realizar conjeturas de 50 segundos durante el mismo período de tiempo.

Desde el punto de vista de una cuenta de usuario, todavía se necesita el mismo número promedio de conjeturas para romper la contraseña, incluso si las conjeturas 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á acelerando en todo el sitio, puede acelerar el acelerador con bastante rapidez.

Refinamientos adicionales:

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

Ideas de interfaz de usuario (puede que no sean adecuadas en este contexto), que también pueden refinar lo anterior:

si usted tiene el control de la configuración de la contraseña, entonces muestra al usuario qué tan segura es su contraseña los alienta a elegir una mejor.
si tiene el control de la página de inicio de sesión , después de un pequeño (digamos 10) número de conjeturas de un solo nombre de usuario, ofrezca un CAPTCHA.

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)

Por lo general, los sitios web solo aplican la política n. ° 1. Incluso la mayoría de los bancos solo aplican la política 1. En su lugar, confían en un & "; Sabe algo más &"; enfoque 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 estructurarlo en una tabla 16 & # 215; 16 y luego pedirle al usuario que le dé el valor en la tabla de la celda A-14, por ejemplo . Cuando un usuario se registre o cambie su contraseña, dele la tabla y dígale que la imprima y la guarde.

La dificultad con ese enfoque es que cuando un usuario olvida su contraseña, como lo hará, no puede simplemente ofrecer el estándar " responda esta pregunta y coloque una nueva contraseña " ;, ya que eso también es vulnerable a la fuerza bruta. Además, no puede restablecerlo y enviarles uno nuevo, 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). Brevemente, el usuario debe cargar una imagen cuando se registra, y cuando intenta iniciar sesión, pídale que elija su imagen entre 8 o 15 (o más) al azar. Entonces, si un usuario carga una imagen de su gatito, en teoría solo ellos saben exactamente qué imagen es la suya de 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.

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

Editar, nueva idea:

Otra forma de validar los intentos de inicio de sesión es verificar si el usuario proviene o no de su página de inicio de sesión. No puede verificar los referentes, ya que pueden ser falsificados fácilmente. Lo que necesita es establecer una clave en _SESSION var cuando el usuario ve la página de inicio de sesión, y luego verificar para asegurarse de que esa clave existe cuando envía su información de inicio de sesión. Si el 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 involucrar a JavaScript en el proceso, ya sea usándolo para configurar una cookie o agregando información al formulario después de que se haya cargado. O bien, puede dividir el formulario en dos envíos 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 enviar).

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 enviaron.

Tengo que preguntar si ha realizado un análisis de costo-beneficio de este problema; Parece que está tratando de protegerse de un atacante que tiene suficiente presencia en la web para adivinar varias contraseñas, enviando quizás 3-5 solicitudes por IP (ya que ha rechazado la limitación de IP). ¿Cuánto (aproximadamente) costaría ese tipo de ataque? ¿Es más costoso que el valor de las cuentas que está tratando de proteger? ¿Cuántas botnets gigantes quieren lo que tienes?

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

Ya había respondido una pregunta muy similar en Cómo ¿puedo limitar los intentos de inicio de sesión de usuario en PHP ? Reitero la solución propuesta aquí, ya que creo que muchos de ustedes lo encontrarán informativo y útil para ver un 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 destructores de CAPTCHA en la actualidad:

No puede simplemente evitar ataques DoS encadenando la aceleración a una sola IP o nombre de usuario. Demonios, ni siquiera puedes evitar los intentos de inicio de sesión rápido con este método.

¿Por qué? Porque el ataque puede abarcar múltiples direcciones IP y cuentas de usuario con el fin de evitar sus intentos de estrangulamiento.

He visto publicado en otros lugares que, idealmente, debería realizar un seguimiento de todos los intentos fallidos de inicio de sesión 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 ciertas demoras en función del número general de inicios de sesión fallidos en un período de tiempo determinado. Debe basar esto en datos estadísticos extraídos de su tabla failed_logins ya que cambiará con el tiempo según la cantidad de usuarios y cuántos de ellos pueden recordar (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 de inicio de sesión fallido 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, imponga la limitación u obligue a todos los usuarios a utilizar un captcha (es decir, reCaptcha) hasta que el número de intentos fallidos durante el período de tiempo determinado sea inferior al 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 cierto umbral garantizaría que un ataque desde múltiples frentes se minimizara y los usuarios normales del sitio no experimentarían un retraso significativo por intentos de inicio de sesión fallidos legítimos. No puedo garantizar la prevención, ya que ya se ha ampliado para que los CAPTCHA puedan ser eliminados. Hay soluciones alternativas, tal vez una variante de & Quot; Nombra a este animal & Quot ;, que podría funcionar bastante bien como un sustituto.

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

usuario + contraseña - > entrada
usuario +! contraseña - > denegado
usuario + conocido_IP (usuario) - > puerta de entrada, // never throttle
usuario + desconocido_IP (usuario) - > catflap
(#denied > n) a través de catflaps (sitio) - > catflaps del acelerador (sitio) // slow the bots
catflap + acelerador + contraseña + captcha - > entrada // humans still welcome
catflap + acelerador + contraseña +! captcha - > denegado // 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 puede 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 las que está intentando contrarrestar.

Parece que está tratando de defenderse contra bruto lento distribuido fuerza . No hay mucho que puedas hacer al respecto. Estamos utilizando una PKI y no hay inicios de sesión de contraseña. Ayuda, pero si sus clientes tienen posibilidades de estaciones de trabajo de vez en cuando, esto no es muy aplicable.

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

Las cookies se pueden robar con XSS y el navegador vulns. Los usuarios suelen cambiar de navegador o borrar sus cookies.

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

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

Múltiples métodos se pueden combinar con éxito, pero el buen gusto está en orden.

La complejidad de la contraseña es buena, cualquier cosa basada en contraseña depende de manera crítica de que las contraseñas tengan suficiente entropía. En mi humilde opinión, una contraseña segura escrita 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 dar a los usuarios la capacidad de imprimir una página grande o pequeña llena de códigos de acceso de un solo uso.

Preguntas de seguridad como " ¿cuál era su mascota de la escuela secundaria " son principalmente otra forma pésima de & "; algo que sabes &"; la mayoría de ellos son fácilmente adivinables o de dominio público.

Como notó, la limitación de los intentos fallidos de inicio de sesión es una compensación entre la prevención de ataques de fuerza bruta y la facilidad de DoSing una cuenta. Las políticas de bloqueo agresivo pueden reflejar una falta de confianza en la entropía de contraseña.

Personalmente, no veo el beneficio de hacer cumplir la caducidad de la contraseña 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 usted. Quizás un beneficio es que el usuario podría 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 & Quot; N intentos fallidos desde el último inicio de sesión & Quot; 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, tokens de hardware en & Quot; algo que tienes & Quot; son geniales, pero muchos (no todos) tienen una sobrecarga administrativa real asociada con su distribución. No sé de ningún & "Biométrico; algo que eres &"; soluciones buenas para sitios web. Algunas soluciones de dos factores funcionan con proveedores de OpenID, algunas tienen SDK de PHP / Perl / Python.

Mi mayor recomendación es simplemente asegurarse de que mantenga a los usuarios informados de los intentos de inicio de sesión incorrectos en sus cuentas: Es probable que los usuarios tomen la seguridad de su contraseña mucho más en serio si se les presenta evidencia de que alguien realmente está tratando de ingresar a su cuenta.

En realidad atrapé a alguien que pirateó la cuenta de MySpace de mi hermano porque habían intentado ingresar 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.

¿Qué hay de requerir 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 tener muchas oportunidades de adivinar la contraseña principal?
Mantenga un conteo / tasa global de fallas de inicio de sesión, este es el indicador de un ataque, durante un ataque sea más estricto con respecto a las fallas de inicio de sesión, p. prohibir las IP más rápidamente.

No creo que haya una respuesta perfecta, pero me sentiría inclinado a tratar de confundir a los robots si se detecta un ataque.

Fuera de mi mente:

Cambie a una pantalla de inicio de sesión alternativa. Tiene varios 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 campo 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, obtendrá una nueva ID de sesión.

Se asume que cualquier formulario que se envíe con datos en un campo incorrecto proviene de un robot: el inicio de sesión falla, punto y esa IP se limita. Asegúrese de que los nombres de campo aleatorios nunca coincidan con los nombres de campo legítimos para que alguien que usa algo que recuerda las contraseñas no sea engañoso.

A continuación, ¿qué tal un tipo diferente de captcha: tienes una serie de preguntas que no causarán problemas a un humano. Sin embargo, son NO al azar. Cuando comienza el ataque, todos reciben la pregunta # 1. Después de una hora, la pregunta n. ° 1 se descarta, nunca se volverá a utilizar y todos recibirán la pregunta n. ° 2, y así sucesivamente.

El atacante no puede probar la descarga de la base de datos para colocarla en su robot debido a la naturaleza desechable de las preguntas. Tiene que enviar nuevas instrucciones a su botnet en una hora para poder hacer cualquier cosa.

Dado que varias personas incluyeron CAPTCHA como mecanismo humano alternativo, estoy agregando una pregunta y un hilo de StackOverflow anteriores sobre la efectividad de CAPTCHA.

¿ReCaptcha ha sido descifrado, pirateado, OCR, derrotado o roto?

El uso de CAPTCHA no limita las mejoras de su limitación y otras sugerencias, pero creo que la cantidad de respuestas que incluyen CAPTCHA como alternativa deberían considerar los métodos humanos disponibles para las personas que buscan violar la seguridad.

También podría acelerar según la seguridad de la contraseña de un usuario.

Cuando un usuario registra o cambia su contraseña, usted calcula una calificación de fortaleza para su contraseña, digamos entre 1 y 10.

Algo así como " contraseña " puntúa 1 mientras que " c6eqapRepe7et * Awr @ ch " podría obtener un puntaje de 9 o 10 y cuanto mayor sea el puntaje, más tiempo demorará la aceleración.

La primera respuesta que generalmente escucho cuando hago esta pregunta es cambiar los puertos, pero olvídate de eso y simplemente deshabilita IPv4. Si solo permite clientes de redes IPv6, ya no rezará por un escaneo de red simple y los atacantes recurrirán a las búsquedas de DNS. No ejecute en la misma dirección que su Apache (AAAA) / Sendmail (MX - & Gt; AAAA) / lo que le ha dado a todos (AAAA). ¿Asegúrate de que tu zona no puede ser transferida, espera que permitas que alguien descargue tu zona?

Si los bots encuentran que su servidor configura nuevos nombres de host, simplemente agregue un poco de galimatías a sus nombres de host y cambie su dirección. Deje los nombres antiguos e incluso configure los nombres ** honeypot para que la red de bots agote el tiempo de espera.

** Pruebe sus registros inversos (PTR) (bajo ip6.arpa.) para ver si pueden usarse para poner a cero en los / 4 que tienen registros VS / 4 que no. ES DECIR. Típicamente, ip6.arpa tendría ~ 32 & Quot;. & Quot; s en una dirección, pero intentar 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 ir tan lejos como VPNing en una DMZ ... Aunque uno se pregunta por qué esa no es la primera opción.

También Kerberos es genial, pero IMHO LDAP explota (¿Qué tiene de malo técnicamente NISPlus? He leído que Sun decidió que los usuarios querían LDAP y por eso dejaron NIS +). Kerberos funciona bien sin LDAP o NIS, solo tiene que administrar usuarios host por host. El uso de Kerberos le brinda una PKI fácil de usar, si no automatizada.

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

Una cosa que podría hacer, especialmente si el sistema parece estar bajo ataque, ya que hay muchos intentos de contraseña incorrecta 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 sus padres , por ejemplo. Si un atacante llega a un millón de cuentas probando la contraseña 'contraseña1', hay una buena posibilidad de que obtenga mucho, pero sus probabilidades de obtener también los nombres correctos reducirían drásticamente los éxitos.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow