¿Los tiempos de carga adicionales en los intentos de inicio de sesión pueden ser una amenaza para la seguridad?

2

Tengo una aplicación web creada con PHP con una página de inicio de sesión donde el visitante debe ingresar la dirección de correo electrónico y la contraseña correspondiente de su cuenta.

Ya que estoy usando la función de hashing nativo (lento) de PHP, cada vez que un visitante ingresa al correo electrónico de una cuenta existente, usará la función de verificación de contraseña para verificar si la contraseña es correcta. Esto también aumenta el tiempo de carga de la página en aproximadamente 0,5 segundos debido al proceso de verificación de contraseña.

Si no existe una cuenta de usuario con el correo electrónico de entrada, la página se carga rápidamente porque ni siquiera intentará verificar la contraseña si no hay nada contra lo que verificar.

Dado que cualquier persona que intente ejercer una fuerza bruta probablemente se dará cuenta de que existe una cuenta de usuario para el correo electrónico de entrada debido al tiempo de procesamiento adicional de la página, ¿sería una posible amenaza para la seguridad?

Nota: solo estoy mostrando un error de inicio de sesión genérico según lo recomendado por OWASP. Así que eso no es un problema.

    
pregunta Kid Diamond 10.09.2014 - 22:01
fuente

5 respuestas

4

Este es un tipo de ataque de tiempo , que conduce a un enumeración de nombre de usuario .

Si esto es una amenaza o no, depende del diseño de su sistema. Si se supone que los nombres de usuario son privados, es una preocupación. Algunos sistemas se escriben de forma tal que la enumeración de usuarios se adapte al diseño, como los proveedores de correo electrónico, ya que las direcciones de correo electrónico son generalmente públicas y si alguien tiene la dirección de correo electrónico [email protected] , definitivamente tienen algún tipo de cuenta de correo electrónico en example.com y no se filtra nada al permitir que otros usuarios sepan que existe. El nombre de usuario que es público conlleva un mayor riesgo, ya que un atacante sabrá a qué cuentas pueden dirigirse. Sin embargo, en un sistema de correo electrónico, esto puede lograrse si un atacante envía un correo electrónico a la dirección para averiguar si rebota, por lo que es poco lo que puede hacer para reducir este vector de ataque en este caso (si desea errores tipográficos en las direcciones de correo electrónico). notificado al remitente por supuesto).

Básicamente, la vulnerabilidad es resumió bien aquí :

  

Como atacante si puedo usar su página de inicio de sesión u contraseña olvidada para limitar mi lista de 10000 objetivos a 1000 objetivos, lo haré.

A veces se asume que si un sitio web permite el registro del usuario con nombres de usuario elegidos o un restablecimiento de contraseña, la enumeración del usuario siempre es posible. Este no es siempre el caso : un sistema de registro de usuarios se puede combinar con un sistema de restablecimiento de contraseña y permitir que un usuario seleccione una dirección de correo electrónico única como su nombre de usuario sin revelar a otras partes que ya está en uso. Esto se logra devolviendo siempre el mismo mensaje al usuario en el sitio web, pero enviando el enlace al siguiente paso del proceso a la dirección proporcionada. Esto garantiza que solo alguien con acceso a esa dirección de correo electrónico pueda registrarse o restablecer la contraseña. Por supuesto, esto sería para un sistema de seguridad medio en el que se supone que un MITM de correo electrónico u otro compromiso no es un vector de ataque viable o que valga la pena.

Los ataques de tiempo por su propia naturaleza tomarán tiempo para que un atacante los ejecute. Por lo tanto, es posible que quieran usar este ataque en su sistema para limitar su lista antes de intentar un ataque de fuerza bruta en los intentos de inicio de sesión "lentos", lo que también llevará tiempo.

Si desea restringir el vector de ataque, debe introducir un retraso artificial que haga que todos los inicios de sesión tengan un nombre de usuario válido o no tomen la misma cantidad de tiempo.

    
respondido por el SilverlightFox 11.09.2014 - 17:22
fuente
2

Estoy de acuerdo en que esto podría verse como algo así como un ataque de canal lateral. Podría representar una amenaza importante, pero depende de las circunstancias, ya que la mayoría de las páginas de registro le dirán si un correo electrónico ya está registrado. Esto podría ser un problema en el que a los usuarios se les asigna un nombre de usuario aleatorio, como un banco que asigna una ID de cliente.

Solo hash la contraseña proporcionada, independientemente de si se encuentra un usuario, si no se encuentra un usuario, use algo arbitrario como sal. Esto hará que tome mucho tiempo, independientemente de si se encuentra un usuario.

    
respondido por el thexacre 11.09.2014 - 00:21
fuente
2

No veo esto como una amenaza importante. Sí, le da a un atacante una forma de verificar que existe un nombre de usuario determinado, pero en una aplicación típica, hay muchas otras formas de obtener esta información.

Si desea evitar este ataque de tiempo, puede volver a escribir su página de inicio de sesión para modificar la contraseña antes de verificar si existe el nombre de usuario, lo que ralentiza todos los intentos de inicio de sesión fallidos a la misma velocidad.     

respondido por el Mark 11.09.2014 - 01:59
fuente
2

Sí : esta es una amenaza para la seguridad.

Como han señalado otros, este es un ataque de canal lateral. Aunque sigue las recomendaciones de OWASP y devuelve el mismo mensaje, aún le está revelando a un atacante si existe una cuenta en particular.

Si estuviera usando nombres seleccionados por el usuario, yo diría que déjelo. En ese caso, el proceso de registro revela qué nombres de usuario existen.

Sin embargo, existen riesgos particulares con las direcciones de correo electrónico que significan que debes solucionarlo. Específicamente:

  1. Una dirección de correo electrónico está vinculada a una persona, y si usan su sitio o no es información privada. Si su sitio era pornografía o reclutamiento, revelar que [email protected] es un miembro podría ser embarazoso para ellos.

  2. Esto permite que los spammers realicen ataques dirigidos de phishing. Pueden comenzar con una lista de direcciones de correo electrónico, utilizar la filtración para determinar cuáles son válidas en su sitio y enviar un correo electrónico de suplantación de identidad a esos usuarios.

La mejor solución es realizar el hash lento en la contraseña, independientemente de si el usuario existe.

    
respondido por el paj28 11.09.2014 - 18:07
fuente
-2

Una mitigación que no vi mencionada es agregar un Google reCAPTCHA (o similar). Esto evitará los intentos de "fuerza bruta", que es lo que está buscando abordar. Solo asegúrese de realizar la validación reCAPTCHA antes de validar las credenciales enviadas. Agregar esta funcionalidad aún le permite a uno realizar ataques de tiempo siempre y cuando ingresen los valores reCAPTCHA correctos. Si esto es preocupante, es probable que haya problemas más importantes que abordar (es decir, una estrategia de mitigación planificada para posibles vulnerabilidades de 0 días).

    
respondido por el anon 11.09.2014 - 22:49
fuente

Lea otras preguntas en las etiquetas