Estoy trabajando en una aplicación web, la seguridad es de alta prioridad. Por lo tanto, si un usuario no ha podido iniciar sesión más de 3 veces, la cuenta se bloqueará. ¿Debo mostrar un mensaje al usuario que diga "su cuenta ha sido bloqueada"? Ayudaría al atacante a obtener el nombre de usuario.
Debe decirle al usuario que la cuenta ha sido bloqueada; de lo contrario, no veo cómo manejaría esa situación sin mostrar un mensaje directamente en la aplicación web. Por supuesto, lo más probable es que le envíe un correo electrónico con algunos pasos para desbloquear su cuenta, pero aún así, debe notificar al usuario dentro de la aplicación que le ha enviado un correo electrónico.
Ahora, considerando su principal preocupación, que es que un atacante podría crear una lista de los nombres de usuario registrados en su sitio web, existe una solución para mitigar este problema.
Seguimiento de intentos por cookies / campos ocultos / entradas de base de datos
Cuando un usuario intenta iniciar sesión con un nombre de usuario inexistente, puede hacer un seguimiento de su intento fallido almacenando la información en una cookie, un campo oculto o incluso directamente en su base de datos. De esa manera, si bloquea una cuenta real después de 3 intentos fallidos, puede hacer un seguimiento de los intentos fallidos (que no son intentos fallidos reales porque el nombre de usuario no existe realmente) y mostrar el mensaje de bloqueo exactamente como en una cuenta real. situación.
La forma más transparente y eficiente de implementar esto sería insertando los intentos fallidos en una base de datos, porque el usuario siempre puede modificar los campos ocultos y las cookies, lo que eventualmente podría ayudarlo a descubrir su pequeño truco. Además, puede ser difícil hacer un seguimiento de los intentos de nombre de usuario inexistentes si el usuario intenta usar varios nombres de usuario mediante cookies y campos ocultos. Sin embargo, en la base de datos, simplemente puede registrar la IP del usuario, el nombre de usuario inexistente y, finalmente, la cantidad de intentos fallidos que indicarán si debe mostrar el mensaje de bloqueo falso o no a su aplicación web.
También es posible que no desee filtrar los intentos solo por IP, en caso de que el atacante use un proxy y pruebe el mismo nombre de usuario y los avisos que le tomó de nuevo, por ejemplo, 3 intentos de bloquear la cuenta. Una vez más, podría descubrir tu truco de esta manera.
Pero, ¿realmente necesitas tal protección?
Antes de implementar una protección de este tipo, tómese un tiempo para pensar si es realmente necesario para su aplicación web. Una situación en la que esto sería completamente inútil es un sitio web que tiene un foro donde los usuarios inician sesión con el mismo nombre de usuario que se muestra en dicho foro. Obviamente, un usuario malintencionado podría construir una lista de los usuarios registrados con bastante facilidad simplemente navegando por las páginas.
Iniciar sesión usando la dirección de correo electrónico
¿Ha pensado en usar la dirección de correo electrónico del usuario para conectarse a su aplicación web, si es posible? Es mucho menos probable que alguien intente construir una lista de direcciones de correo electrónico ya que hay muchas más posibilidades que los nombres de usuario (los usuarios tienden a elegir nombres de usuario típicos y simples como "Simon" cuando está disponible. Sin embargo, la búsqueda de Simon's e La dirección de correo electrónico es más difícil, ya que hay muchos servicios de correo electrónico posibles, asumiendo que eligió el nombre de usuario "Simon" (p. ej. [email protected], [email protected], [email protected], etc.)) .
Si bien la respuesta de @ Simon es excelente, me gustaría agregar un punto adicional. No bloquee las cuentas de usuario debido a intentos fallidos de inicio de sesión .
Al hacerlo, está introduciendo una gran vulnerabilidad de DoS en su aplicación. Cualquier atacante malintencionado simplemente puede bloquear una gran cantidad de usuarios al fallar repetidamente el proceso de inicio de sesión. También presentará un gran dolor de cabeza de soporte porque los usuarios fallarán el proceso de inicio de sesión. A veces repetidamente. Recuerde la tercera faceta del triángulo de la CIA, Disponibilidad. Su aplicación es inútil si nadie puede usarla.
En su lugar, lo que debe hacer es limitar la cantidad de intentos de inicio de sesión permitidos. Introduzca un período de "tiempo de espera" en lugar de bloquear permanentemente la cuenta del usuario en espera de alguna acción por parte de los usuarios. Esto detendrá suficientemente los ataques de fuerza bruta en línea y mantendrá los correos electrónicos de soporte y las llamadas a un nivel razonable.
Si obtienes muchos intentos de contraseña, debes bloquear al atacante , no a la víctima . Esto debería ser obvio, pero es un problema bastante común de todos modos.
En primer lugar, ralentiza el ataque. Después de un solo intento de contraseña incorrecta, la IP que envió el intento no debería poder enviar otra hasta que hayan transcurrido varios segundos. Puede enmascarar esto en el lado del navegador mostrando un mensaje de "autenticación, espere ...". Pero en el backend, si obtienes más de un intento en un solo N por segundo IP desde una IP determinada, luego devuelve un mensaje de error que le informa al atacante que ni siquiera vas a Compruebe para ver si su suposición era correcta.
Para obtener puntos de bonificación, requiera N segundos de silencio, no solo N segundos desde la primera estimación. De esa manera, vencer en el servidor solo prolonga el tiempo de espera.
Segundo, bloquee las direcciones IP ofensivas, no las cuentas ofendidas. Puede ampliar fácilmente su solución desde el punto anterior para aumentar el tiempo de espera después de que los intentos N hayan fallado. Entonces, por ejemplo, 10 intentos y obtienes 15 minutos adicionales en el cuadro de penalización. Incluso podría mostrar un amistoso temporizador de cuenta regresiva en su página web. También es útil decirle a la gente "3 intentos restantes" para que piensen en lo que escriben, y no se limiten a eliminar las contraseñas malas hasta que queden bloqueadas.
Tercero, responde a los ataques haciéndolo menos amigable con los robots. Si una sola cuenta está recibiendo atención de cientos de IP, cambias las cosas para romper los bots. Poner un desafío CAPTCHA, por ejemplo. Los usuarios reales pueden encontrarlo molesto, pero no tan casi tan molesto como el bloqueo de su cuenta.
No mostrar el mensaje de error no agrega mucho valor para la seguridad, mientras que es una mala experiencia para el usuario, ya que es muy conveniente para el usuario saber cuál es el problema con la entrada de inicio de sesión. Si su sistema requiere alta seguridad, puede usar un sistema de castigo por tiempo de espera y un mejor marco de contraseña.
Lea otras preguntas en las etiquetas web-application authentication