¿Está negando el inicio de sesión después de intentos incorrectos ineficaz?

La prevención del inicio de sesión sin la contraseña correcta es la funcionalidad principal del proceso de inicio de sesión. Seguir haciendo eso no es de ninguna manera una función de seguridad "adicional".

Negar intentos de inicio de sesión después de X intentos incorrectos significa rechazar todos intentos en esa situación, independientemente del valor de la contraseña que se presenta. Si aún acepta la contraseña correcta, entonces no está negando nada, solo está administrando un proceso de inicio de sesión.

Con los sistemas en línea, deshabilitar la cuenta es un poco imprudente; significa que cualquiera puede bloquear su cuenta de manera efectiva al ingresar contraseñas no deseadas. Un procedimiento más suave es agregar retrasos : después de X contraseñas incorrectas, haga que el servidor bloquee la cuenta, por ejemplo, un minuto, y la vuelva a bloquear por un minuto después de cada intento hasta que se ingrese la contraseña correcta. Los intentos iniciales de X deberían ser suficientes para hacer frente a los usuarios con dedos temblorosos, y la tasa de uno por minuto impide gravemente a un atacante forzoso (junto con algunas medidas de seguridad, como la prohibición de direcciones IP de las cuales demasiadas solicitudes de inicio de sesión llegan en muy poco tiempo) .

La idea es ni siquiera aceptar la contraseña correcta durante el bloqueo.

Pero antes de implementar un sistema de bloqueo, tiene sentido mirar los casos de ataque:

un usuario específico está dirigido

Si el atacante está apuntando a un usuario específico, es útil negar o retrasar el inicio de sesión después de un par de intentos erróneos. Un error común con el enfoque de retraso es no impedir los intentos de inicio de sesión paralelos.

Otro enfoque común es usar CAPTCHA para ralentizar al atacante. Hay que tener en cuenta que muchos CAPTCHA estándar ya están rotos. Cuando se manipuló la votación del NY-Times, los atacantes crearon una interfaz especial que muestra muchos CAPTCHA en una página.

El atacante puede intentar solo dos intentos de inicio de sesión por día durante un largo período de tiempo (en realidad lo vemos en Stendhal de vez en cuando). Mostrar el número de intentos de inicio de sesión fallidos después de un inicio de sesión exitoso puede ayudar aquí Es importante no decir "0 intentos de inicio de sesión fallidos" cada vez, porque esto solo enseñará a las personas a ignorar ese mensaje. Solo muestre la advertencia si hubo al menos un intento fallido de inicio de sesión.

Una lista de direcciones IP y marcas de tiempo de los últimos intentos de inicio de sesión (con éxito o no) puede ayudar, al menos para los usuarios que se preocupan por la seguridad y tienen un cierto nivel de conocimiento.

cualquier usuario es el objetivo

En los casos en los que se intenta un número realmente grande de inicios de sesión, los atacantes a menudo escogen una contraseña fija y forzan los nombres de las cuentas. Esto significa que no se activará un umbral de tres intentos de inicio de sesión por cuenta.

Por lo tanto, los intentos de inicio de sesión fallidos deben rastrearse en una cuenta cruzada, por ejemplo, en función de las direcciones IP.

bloqueando un gran número de usuarios

La implementación de las medidas de contador mencionadas anteriormente crea una nueva vulnerabilidad: un atacante puede bloquear un gran número de cuentas. En algunos casos, esto puede causar un daño mucho mayor en un sitio que una pequeña cantidad de cuentas pirateadas.

el conteo basado en IP puede ayudar a mitigar este vector de ataque. O puede darle una palanca en situaciones en las que muchas personas están detrás del mismo servidor proxy (en una universidad o en una red pública, etc.)

bloqueo de una cuenta específica

Además de la última sección, un atacante puede intentar bloquear una cuenta específica. Por ejemplo, alguien que está ofertando contra ellos en una subasta.

Puede ser posible usar un segundo canal para permitir que el propietario de la cuenta vuelva a habilitar su cuenta. Por ejemplo, enviando un mensaje de texto móvil o un correo electrónico con un código.

Me gusta la respuesta de Thomas Pornin. Mi única adición sería: cuando diseñe una función de bloqueo de contraseña, necesita descubrir cómo respaldar su base de usuarios y equilibrarla con el riesgo de interrupciones.

En un sistema de alta seguridad con un número limitado de usuarios expertos en seguridad, administradores dedicados y un gran presupuesto para el soporte al usuario, habilitar una contraseña bloqueada puede ser manual y puede requerir una nueva autenticación a través de un canal secundario que sea costoso y consume mucho tiempo.

En un sistema de baja seguridad con una base de usuarios enorme (y tal vez incluso analfabeta), como Google o Hotmail, es probable que el riesgo de una interrupción sea superado por el gasto del desbloqueo de la cuenta de soporte a través de cualquier cosa excepto una Proceso automatizado, muy sencillo.

He visto sistemas que eran tan simples que lo único que hicieron fue cerrar el navegador cuando se alcanzaron 3 contraseñas incorrectas. Un poco mejor es el sistema que Thomas propuso con un tiempo de espera en cuentas deshabilitadas. En mi experiencia, los sistemas hacen esto para proporcionar una barrera moderada a los ataques de fuerza bruta mientras equilibran las necesidades de toneladas de usuarios que intentan acceder a sus cuentas.

Es cierto que no es el mejor enfoque, pero los sistemas necesitan encontrar una forma de frenar los ataques mientras no se enfrentan a los usuarios cara a cara, ya que cada llamada de soporte le cuesta dinero al proveedor, por lo que con servicios gratuitos como Gmail, obtendrá lo que pagas.

Le sugeriría que no solo bloquee un perfil de usuario que tenga demasiadas contraseñas malas ... sino que también bloquee la IP de una máquina que tenga demasiadas contraseñas malas (posiblemente con varias cuentas).

Uso DenyHosts en mis máquinas Linux para bloquear las IP que intentan adivinar contraseñas.

Creo que deberías dejar que el usuario determine cuán "aleatoria" es su contraseña.

Para algunas "contraseñas", simplemente no tiene sentido poner un límite: algunos usuarios generan sus "contraseñas" automáticamente (haciéndolas imposibles de recordar) y las guardan en un archivo, por lo que estas contraseñas son más como criptografía. claves que las contraseñas normales.

Creo que permite al usuario elegir cuántos intentos antes de que la cuenta obtenga una penalización de 10 s, 30 s, 1 mn de tiempo de inicio de sesión y cuántos antes de que la cuenta se bloquee durante 1 h, 12 h, 1 d , con o sin el recurso CAPTCHA obligaría al usuario a pensar más en la fortaleza de su contraseña.

Entonces, no solo le está dando algo de libertad a las personas, está forzando esta libertad a los usuarios : cada usuario tendría que elegir una política de bloqueo.

También se debe permitir que un usuario vincule su cuenta a algún RBL para evitar el inicio de sesión desde los relés SOCKS abiertos o desde las salidas de Tor (de forma predeterminada, sin RBL suscrito).

Para las aplicaciones web, un usuario debe tener el derecho de elegir entre autenticación pura basada en HTTP (autenticación HTTP, cookies, ...) o autenticación basada en IP + HTTP basada en HTTP (vinculando a un usuario que haya iniciado sesión a una IP) (por defecto solo para autenticación basada en HTTP, sin enlace de IP).

Creo que deberías dar agresivamente libertad y responsabilidad a los usuarios. De esta manera, no pueden llorar en los foros cuando han sido hackeados, diciendo que la contraseña configuración del sistema era débil, insegura, no profesional ...

Depende mucho de a qué tipo de cuenta está intentando acceder el usuario. Las cuentas de correo electrónico basadas en la Web son el ejemplo habitual donde el correo electrónico es el nombre de usuario, sin embargo, en otros casos es mejor no usar el correo electrónico como nombre de usuario, por lo tanto, el atacante no tendría las credenciales de usuario en primer lugar para descifrar la contraseña. .

Cualquier forma de bloqueo de cuenta sin captchas o alguna otra forma de prevención masiva de POST puede llevar a la denegación de servicio cuando se usa una herramienta de ataque para enviar múltiples solicitudes con el fin expresado de causar bloqueos de cuenta.

El uso de nombres o nombres que no son de correo electrónico es el estándar con los inicios de sesión de cuentas de sitios web como Godaddy y otros, y también los inicios de sesión de cuentas bancarias, por ejemplo, aunque estos tienden a ser cadenas de números, lo que los abre a ataques de denegación de servicio específicos del usuario mediante ataques masivos Ataques de fuerza bruta en bloques de cadenas de números.

ex: usuario: 1000000 ++ pasar: a-zA-Z0-9

Un ataque que envía 4 intentos a un nombre de usuario secuencial donde el banco ha configurado al usuario para que sea un rango de números como 48829387 podría fácilmente permitir que un atacante niegue los inicios de sesión a un gran número de usuarios del banco al sobrepasar el límite de permitido incorrecto las solicitudes de contraseña a números aleatorios entre los rangos de, por ejemplo, 4000000 y 4999999.

Sin embargo, en la mayoría de las situaciones de inicio de sesión web, hacer que los usuarios elijan un nombre de usuario separado de su nombre o dirección de correo electrónico está pidiendo demasiado, y es probable que los bancos usen cadenas de números como nombres de usuario.

Por lo tanto, si los nombres de usuario difíciles no están disponibles como una opción, prevenir el uso inadecuado del diccionario es el siguiente puerto de escala ya sea mediante el uso de captchas o incluso el javascript exigente antes de establecer sesiones, ya que estas herramientas de ataque de tipo diccionario no tienen la capacidad de lidiar con ellas. devolviendo las cookies y mucho menos los sessons establecidos después de que se detecte javascript.