¿Puedo prevenir ataques de temporización con retrasos aleatorios?

Question

¿Puedo prevenir ataques de temporización con retrasos aleatorios?

#1 de Mike Ounsworth (12 votos)
#2 de tim (3 votos)

10

Leí recientemente sobre el perfil de cuentas de usuario válidas con ataques de tiempo, es decir, la aplicación bajo ataque toma un tiempo predeciblemente diferente para procesar, digamos un inicio de sesión en un usuario inexistente de un usuario existente. Sin embargo, nunca he visto en ningún ejemplo ni código marco ninguna protección contra esto. ¿Sería suficiente simplemente insertar un retraso aleatorio antes de la respuesta para que el atacante de la sincronización esté teniendo todo un lío de tiempos de respuesta? Si es así, ¿por qué no he visto esto? Si no, ¿qué tiene de malo este esquema?

authentication timing-attack

pregunta Iain Duncan 10.08.2015 - 21:04

fuente

2 respuestas

3

En teoría, esto no funcionará. El atacante ya tiene aleatoriedad por los retrasos de la red, agregar aleatoriedad adicional no evita los ataques de tiempo, solo significa que el atacante necesita más datos para su análisis.

En la práctica, podría hacer inviables los ataques de tiempo debido a la cantidad de datos necesarios para el análisis

Pero hay mejores formas de prevenir los ataques de tiempo. Para aplicaciones web, los ataques de tiempo se evitan principalmente al realizar cosas en un tiempo fijo. En su ejemplo, eso significaría que desea comparar la contraseña con una contraseña imaginaria, incluso si el nombre de usuario no existe.

Por supuesto, los nombres de usuario generalmente no se consideran información confidencial, y si tienes una página de registro, un atacante podría hacer fuerza bruta en su lugar. Por otro lado, generalmente se recomienda que las comparaciones de contraseñas sean seguras.

respondido por el tim 10.08.2015 - 21:12

fuente

Lea otras preguntas en las etiquetas authentication timing-attack

¿Existen teléfonos celulares con procesadores de banda base de código abierto? ¿Qué es exactamente una subclave?

score 12 · Accepted Answer

Esto es en realidad un error común porque intuitivamente, parece que agregar retrasos aleatorios debería frustrar los ataques de tiempo, hasta que lo pienses un poco más.

Teóricamente, si las longitudes de sus demoras aleatorias no tienen límites, es decir, extraídas de [0, infinity] , frustrarían un ataque de tiempo por la razón que sugiere. En la práctica, usted A) no quiere hacer que los usuarios legítimos esperen una cantidad infinita de tiempo para su inicio de sesión, y B) tiene que sacar sus retrasos aleatorios de un rango finito [0, a] . Esto significa que en promedio (es decir, con suficientes muestras) simplemente está agregando a/2 a la hora.

Entonces, digamos que sin demoras aleatorias tiene los siguientes perfiles de tiempo:

consulta el nombre de usuario existente: x ms
consulta el nombre de usuario no existente: y ms

Con los retrasos aleatorios que tiene ahora (en promedio):

consultar el nombre de usuario existente: x + a / 2 ms
consulta el nombre de usuario no existente: y + a / 2 ms

Desde x - y = (x + a/2) - (y + a/2) , la diferencia de tiempo todavía está ahí para que un atacante la explote. Lo único que ha cambiado es que, además de tener que filtrar el retraso de la red, el retraso de la programación de la CPU, el retraso de equilibrio de carga, etc., también tienen que filtrar el retraso intencional aleatorio. Un ataque de sincronización exitoso ya hará múltiples consultas para cada nombre de usuario y promedio, pero ahora es posible que tengan que agregar más muestras para obtener su promedio "limpio".

Línea inferior : agregar ruido aleatorio puede hacer que el ataque sea más lento, pero no lo hará más complejo.

La única forma real de protegerse contra los ataques de temporización es asegurarse de que cada ruta de código posible lleve la misma cantidad de tiempo.

consulta el nombre de usuario existente: x ms
consulta el nombre de usuario no existente: x ms

Entonces realmente no hay manera de diferenciarlos.

¡Advertencia! Escribir código invariable en el tiempo puede ser complicado, por lo tanto, la máxima "no hagas rodar la tuya". Si puede encontrar un administrador de inicio de sesión que ya implemente invariancia de tiempo, entonces usarlo sería más fácil y más seguro.