Servidor HTTP: tiempo de respuesta en la solicitud de inicio de sesión

Navega tus respuestas
7

Tengo un sitio en el que me gustaría evitar que un atacante no autenticado sepa si existe una cuenta. En el sitio, las contraseñas se procesan mediante bcrypt, por lo que las solicitudes de inicio de sesión deben hacer una comparación de bcrypt (fuerza 12), lo que requiere tiempo de CPU.

Mi preocupación: el tiempo de respuesta del servidor varía según se haya encontrado o no la cuenta del usuario. Si se encontró la cuenta, la comparación de bcrypt se ejecuta para verificar la contraseña; Si no, la función puede volver inmediatamente. En mi máquina local, obtengo ~ 600 ms de tiempo de respuesta cuando se encuentra la cuenta, mientras que obtengo ~ 30 ms de tiempo de respuesta cuando no se encuentra. En producción, solo agregue la latencia de la red a ambos.

En resumen, como cliente, podría determinar si existe una cuenta.

Mi pregunta: ¿Es esto algo de lo que debería preocuparme? Y si es así, ¿cuál es la mejor solución, una espera artificial? ¿Una menor fuerza de criptografía? ¿Un algoritmo hash más rápido?

    
pregunta Dev Chakraborty 19.05.2015 - 20:12
fuente

3 respuestas

5

Sí, deberías preocuparte por esto. Es un posible canal lateral y revela información sobre su sistema. Algunas defensas posibles (que se están utilizando) son:

  • Utilice un retraso de espera mínimo seudo aleatorio. (esto significa que una respuesta válida o no válida tomará aproximadamente la misma cantidad de tiempo)
  • hacer que una respuesta no válida realice todos los pasos de cálculo de una respuesta válida (solo con un valor de retorno no válido). Esto requiere mucha CPU, pero a menudo se emplea por ignorancia. (los ingenieros simplemente hacen que todo pase por todos los pasos)
  • Retraso incremental (cada intento duplica el factor de retraso) el iPhone emplea esto, por ejemplo.
  • Use un servicio de autenticación central que emplee alguna defensa contra esto. ya sea a través del tráfico o por otros medios.
respondido por el LvB 20.05.2015 - 00:32
fuente
1

Creo que Linux usa un retraso cada vez mayor para inicios de sesión no válidos. Por ejemplo, si inicia sesión con un nombre de usuario incorrecto o , habrá una demora de 1 segundo en su primer intento, 2 segundos en su próximo intento, 4 en su tercero, etc. oculta el retraso de cálculo que le preocupa, así como ralentizar a las personas que intentan minar su proceso de autenticación de datos.

La combinación de este retraso con las llamadas a bcrypt, incluso para un nombre de usuario incorrecto, debe proporcionarle una buena cantidad de protección contra los ataques de tiempo.

    
respondido por el Neil Smithline 19.05.2015 - 20:56
fuente
-2

Por lo general, no es un problema que un atacante sepa si el inicio de sesión existe o no, por lo que si no sabe si es importante para usted, probablemente no lo sea. Pero si aún desea ocultar el hecho de que el inicio de sesión no existe, le sugiero que agregue un poco de retraso. Probablemente, la mejor manera será verificar realmente un hash (y finalmente devolver 'falso' de todos modos), por lo que el tiempo de espera dependerá realmente de la carga de la CPU del servidor web, la fuerza de cifrado, etc.

    
respondido por el Timofey 19.05.2015 - 20:19
fuente

Lea otras preguntas en las etiquetas

¿Una autenticación WPA2-PSK solo tiene éxito si ambas partes conocen la clave precompartida? ¿Es posible detectar el tráfico de una red remota? (Con acceso de administrador al enrutador)