¿Son tres buenos intentos de bloquear el inicio de sesión una buena idea?

Si bien la respuesta de Rory es bastante acertada, también agregaría ese bloqueo de cuenta después de los intentos de X, en ciertos contextos, puede ser una forma fácil de causar una denegación de servicio (DoS) contra un usuario legítimo.

Imagina que un proveedor de correo web (como gmail) haya funcionado de esta manera. Si quiero causarle un DoS temporal, todo lo que debo hacer es intentar iniciar sesión como usted con tres (o 5, o lo que sea necesario ... el número real no importa demasiado) veces con la contraseña incorrecta El proveedor de correo web luego bloquearía su cuenta y cuando usted, a pesar de que conozca su contraseña, haya iniciado sesión, no se autenticará.

Es por esto que estas políticas de bloqueo no son tan comunes en los sitios de acceso público en estos días. Un enfoque mejor es poner una demora cada vez mayor entre las solicitudes de contraseña, lo que disuadirá a los guiones de los niños, pero le permitirá ingresar su contraseña. Aún mejor es usar otro factor, como la IP de origen de los intentos de inicio de sesión para decidir ralentizar el indicador de inicio de sesión (o mostrar un captcha en el caso de las cuentas de Google).

Algo en que pensar cuando se debate este tipo de política. Saludos.

Esencialmente, si observa el bloqueo de cuenta, está diseñado para mitigar el riesgo de un ataque de adivinación de contraseña en línea.

Si existe una regla de contraseña razonable (por ejemplo, 8 caracteres + con complejidad y una comprobación de contraseñas comunes), es bastante improbable que un ataque de adivinación de contraseña en línea tenga éxito en un número bajo de intentos.

También vale la pena considerar que el usuario no es amigable con los bloqueos que se producen + el costo comercial de la pérdida de trabajo. Así como con cualquier cosa en seguridad, es un intercambio.

FWIW Sugeriría que para muchos sistemas 5-10 es un número más razonable. Aunque es bastante fácil escribir mal una contraseña 2 o 3 veces, para cuando llegas a 10 es razonable suponer que el usuario la ha olvidado.

Otro factor a considerar es el riesgo regulatorio. Los auditores tienden a tener ideas fijas en este caso, y muchos de sus scripts pueden decir que cualquier cosa sobre 3 es un problema ...

Microsoft tiene un informe sobre este aquí que se detalla en esto. tema.

  

¿Es esta una regla de seguridad común o simplemente una estupida?

Es una política extremadamente común, y podría decirse que, debido al ataque de denegación de servicio que implica, también es una estupidez.

Es bastante estándar en las empresas. Podría argumentar que tiene más sentido aquí donde hay un servicio de asistencia de la empresa para hacer frente a las consecuencias, y esperaría poca motivación para que otro empleado se aproveche del DoS. En este contexto, también es requerido por algunos estándares de seguridad, por ejemplo, PCI DSS. En un contexto orientado al consumidor, donde tiene una mayor variedad de atacantes potenciales y costos más altos para respaldar a los usuarios bloqueados, sería una peor compensación.

El ataque que está intentando bloquear es el de adivinar por fuerza bruta a la cuenta de un usuario específico en particular. Si desea deshacerse del bloqueo de la cuenta, tendrá que encontrar alguna mitigación alternativa para ese ataque. Eso podría incluir:

• requisitos de complejidad de las contraseñas más estrictas: aumentar la entropía en una contraseña podría aumentar considerablemente la cantidad de conjeturas que se espera obtener una infracción;

• autenticación de dos factores; potencialmente, usando factores débiles adicionales como direcciones IP, perfiles de dispositivos y patrones de comportamiento para hacer un juicio de riesgo y posiblemente solicitar un segundo factor o un autenticador adicional;

• límite de velocidad basado en IP / reputación, para retardar el acceso a la interfaz de inicio de sesión progresivamente cuando hay muchos inicios de sesión fallidos recientemente.

Debido a que el mecanismo de bloqueo de la cuenta no intenta protegerse contra el escenario de adivinanzas de fuerza bruta en muchas cuentas (por ejemplo, el ataque de 'adivinanza con contraseña invertida' de elegir una contraseña común y probarla en muchas cuentas), puede que Quiero considerar algunos de estos enfoques en cualquier caso. (La otra mitigación tradicional contra este tipo de ataque es mantener los nombres de usuario semi-secretos, protegiendo contra la enumeración del nombre de usuario, pero esto es un poco débil y puede ser difícil de cubrir completamente para algunos tipos de sistemas).

No estoy seguro de lo que podría ser apropiado en su situación particular, pero como menciona un "mainframe", mi sospecha sería un sistema heredado con pocas posibilidades de cambio. Tampoco está claro qué tipo de "firewall" estaría relacionado con las contraseñas de los usuarios. ¿Se refiere a la autenticación de proxy web?