Autenticación de desafío / respuesta de ataque al solicitar desafíos

Question

Autenticación de desafío / respuesta de ataque al solicitar desafíos

#1 de Neil Smithline (3 votos)

2

Si una aplicación cliente / servidor usa un patrón de desafío / respuesta para la autenticación, por ejemplo. SCRAM o similar, a menudo implica el uso de nonces (cliente nonce y servidor nonce) para prevenir ataques de repetición.

El servidor generará un nonce de servidor, basado en un número aleatorio seguro generado concatenado con el nonce del cliente. Suponiendo que el servidor almacena el archivo de cliente recibido más reciente y el servidor emitido para garantizar que no se aceptarán los archivos "más antiguos" o "no válidos", esto abrirá un vector de ataque.

Un atacante podría hacer una solicitud de fuerza bruta contra los ID de usuario que adivina, para anular la condición de cliente / servidor válida y acordada con un nuevo valor, que el cliente real no sabe. Si esto sucede entre el desafío y la respuesta del cliente real, el servidor denegará el acceso, ya que el nonce ya no será válido. Lo que sería algún tipo de ataque de denegación de servicio.

Si el servidor decide solo actualizar el servidor / cliente realmente válido en el almacenamiento solo si el desafío / respuesta se ejecutó con éxito en su totalidad, tendría que rechazar las solicitudes de desafío para los usuarios que no han respondido al desafío más reciente . Esto también abriría una ventana de ataque. El ataque podría solicitar desafíos a los usuarios (adivinados) para evitar que soliciten un desafío en primer lugar.

Suponiendo que el servidor mantendrá un registro de una lista de nonces no utilizados, se evitarían ambos ataques, pero esto abre otro vector para que el atacante solicite una gran cantidad de desafíos, lo que lleva al servidor a almacenar todos esos nonces en el almacenamiento. Provocar la carga de E / S y potencialmente llevar a DoS nuevamente.

De todos modos, actualmente no entiendo cómo implementar de manera segura el manejo de nonce en el lado del servidor para evitar esos ataques DoS. Actualmente tengo la sensación de que uno intercambia la protección contra ataques de repetición a favor de DoS.

Sé que existen otros medios para evitar esto, mediante la limitación de solicitudes en los cortafuegos, etc., pero me gustaría resolver este problema en el nivel de implementación de desafío / respuesta, si es posible. Gracias por ideas y respuestas.

authentication attacks attack-prevention challenge-response

pregunta Tobias N. Sasse 20.04.2016 - 14:37

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication attacks attack-prevention challenge-response

¿Cómo “pasar el hash” cuando el hash de LM está deshabilitado? ¿Cómo bloquear I2P y Freenet a mi red?

score 3 · Accepted Answer

Las dos preocupaciones que has planteado son:

Un atacante que no conoce la contraseña puede modificar la copia de la lista de servidores del servidor.
A medida que la lista de servidores del cliente crece sin límites, puede usarse en un DoS.

Una técnica común es limitar el tiempo de los nonces. Digamos, para M minutos para una M. apropiada

Para el primer problema, al limitar el tiempo las fallas, el servidor puede mantener múltiples sesiones de autenticación con el cliente, cada una de las cuales realiza un seguimiento de su propia nonce. Esto no es una gran pérdida de recursos en el servidor, ya que estas sesiones se eliminan automáticamente después de M minutos.

El segundo problema se resuelve con un número limitado de clientes que restringen el tiempo. Para que esto funcione, el cliente debe incluir una marca de tiempo. De lo contrario, está abierto a los ataques de repetición posteriores al tiempo de espera, cuando el servidor borra sus nonces caducados, con lo que "olvida" los nonces utilizados. Así que el nonce del cliente debería ser timestamp + secure random number . Al incluir la marca de tiempo en el nonce, se asegura de que el nonce no se pueda usar después del tiempo de espera.

Al determinar el valor de M, debe ser lo suficientemente grande para manejar los tiempos de comunicación de la red y las diferencias de reloj entre el servidor y el cliente. M debe ser lo suficientemente pequeño como para reducir suficientemente sus necesidades de recursos. M siendo 1, o incluso menos de 1, puede ser apropiado si no se requiere la interacción del usuario durante el proceso de autenticación. Si se requiere la entrada del usuario, se necesitará una M más grande.

Un atacante con muchos recursos aún puede ser capaz de ejecutar un DoS sobre ti ya que todavía hay una ventana de M minutos para que esto ocurra. Pero esta es una ventana pequeña y requeriría muchos recursos de atacante. Es decir, sería un DDoS y no un DoS directo. Los ataques DDoS sobrevivientes son un problema propio.