Pregunta

Es evidente que algún tipo de mecanismo para limitar los intentos de inicio de sesión es un requisito de seguridad. Aunque me gusta el concepto de un tiempo exponencialmente creciente entre los intentos, lo que no estoy seguro de almacenar la información. También estoy interesado en soluciones alternativas, preferiblemente sin incluir los captchas.

Estoy adivinando una cookie no funcionaría debido al bloqueo de cookies o borrarlos de forma automática, pero trabajaría sesiones? ¿O tiene que ser almacenada en una base de datos? No ser consciente de qué métodos pueden / se están utilizando por lo que simplemente no sé lo que es práctico.

¿Fue útil?

Solución

Utilice algunas columnas en la tabla de usuarios 'FAILED_LOGIN_ATTEMPTS' y 'failed_login_time'. Los primeros incrementos por inicio de sesión fallido, y se restablece en inicio de sesión correcto. El segundo le permite comparar el tiempo actual con la última vez fallado.

El código puede utilizar estos datos en el PP para determinar cuánto tiempo se espera para bloquear a los usuarios, el tiempo entre el inicio de sesión permitidos, etc.

Otros consejos

Suponiendo que Google ha hecho las pruebas necesarias facilidad de uso (no una suposición injusta) y decidió utilizar los captchas, sugeriría ir junto con ellos.

El aumento de los tiempos de espera es frustrante cuando estoy un usuario genuino y olvidado mi contraseña (con tantos sitios web y sus contraseñas asociadas que sucede mucho, sobre todo a mí)

El almacenamiento de intentos en la base de datos es la mejor solución en mi humilde opinión, ya que le da los registros de auditoría de los intentos de violación de la seguridad. Dependiendo de la aplicación puede o no puede ser un requisito legal.

Mediante el registro de todos los intentos fallidos también puede recopilar información superior nivel, como si las solicitudes son procedentes de una dirección IP (es decir, alguien / algo está intentando un ataque de fuerza bruta) para que pueda bloquear la dirección IP. Esta información puede ser muy útil.

Una vez que haya determinado un umbral, ¿por qué no los obligue a solicitar el envío de correo electrónico a su dirección de correo electrónico (es decir, similar a 'He olvidado mi contraseña'), o usted puede ir para el enfoque CAPCHA.

Bloquear la política es todo muy bien, pero hay un equilibrio.

Una consideración es que pensar en la Construccion de nombres de usuario - adivinar? Pueden enumerarse en absoluto?

Yo estaba en una Prueba de penetración aplicación externa para un punto com con un portal del empleado que sirvió de Outlook Web Access / Intranet, ciertas aplicaciones. Era fácil enumerar los usuarios (el / Equipo Managament Exec en el propio sitio Web, ya través de empresas como Google, Facebook, LinkedIn, etc.). Una vez que tenga el formato del inicio de sesión nombre de usuario (nombre y luego el apellido entró como una sola cadena) que tenía la capacidad de cerrar 100 de los usuarios debido a sus 3 strikes y fuera de política.

Las respuestas en esta base de datos priorizar posterior centrados soluciones, ya que proporcionan una estructura de registros que hacen la auditoría y la lógica de bloqueo conveniente.

Si bien las respuestas aquí frente a los ataques de adivinanzas sobre los usuarios individuales, una de las principales preocupaciones con este enfoque es que deja el sistema abierto a ataques de Denegación de Servicio . Todas y cada petición de que el mundo debe no el trabajo de base de datos de activación.

Una alternativa (o adicional) capa de seguridad debe ser implementado antes en el ciclo req / res para proteger la aplicación y la base de datos a partir de realizar el bloqueo a cabo operaciones que pueden ser costosos y no son necesarias.

Express-bruta es un excelente ejemplo que utiliza Redis almacenamiento en caché para filtrar malicioso peticiones al tiempo que permite los honestos.

Usted sabe lo que es ser golpeado ID de usuario, mantenga una bandera y cuando alcanza un valor umbral, simplemente dejar de aceptar cualquier cosa por ese usuario. Pero eso significa que almacena un valor de datos extra por cada usuario.

  

Me gusta el concepto de un tiempo exponencialmente creciente entre los intentos, [...]

En lugar de utilizar de manera exponencial aumento de tiempo, en realidad se podría tener un retraso aleatorio entre los intentos sucesivos.

Tal vez si se le explica lo que la tecnología que está utilizando la gente aquí será capaz de ayudar con ejemplos más específicos.

Almacenar la información del lado del servidor. Esto le permitiría a defender también contra ataques distribuidos (procedentes de varias máquinas).

Es posible que quiera decir bloque de la entrada por un tiempo digamos por ejemplo, 10 minutos después de 3 intentos fallidos por ejemplo. El crecimiento exponencial de tiempo suena bien para mí. Y sí, almacenar la información en la sesión del lado del servidor o base de datos. Base de datos es mejor. Sin galletas de negocios, ya que es fácil de manipular por el usuario.

También es posible que desee asignar esos intentos contra el cliente adrress IP, ya que es muy posible que el usuario válido podría obtener un mensaje bloqueado mientras que otra persona está tratando de adivinar la contraseña de usuario válido con intentos fallidos.

scroll top