Si solo usamos el cliente y no el servidor, ¿qué vectores de ataque son posibles?

Question

Si solo usamos el cliente y no el servidor, ¿qué vectores de ataque son posibles?

#1 de Peter Harmann (3 votos)

1

Como todos sabemos, se necesita nonce para evitar los ataques de repetición. En todas partes que leo sobre nonce, veo que el cliente siempre obtiene uno del servidor, y , para mejorar aún más la seguridad, también puede agregar su propio nonce de cliente (cnonce).

Al igual que en este diagrama:

Este esquema agrega una sobrecarga de un viaje de ida y vuelta más al servidor; y estoy tratando de averiguar qué vectores de ataque serán posibles si solo usamos el cliente nonce, y nos aseguramos en el servidor que nunca se reutilicen los códigos (para evitar el almacenamiento de todos los códigos usados, obviamente podríamos requerir que cada próximo cnonce para una clave de API dada es mayor que el anterior, y solo almacena el último cnonce para la clave de API dada).

Hasta ahora no encuentro ningún nuevo vector de ataque: al garantizar que cnonces nunca pueda reutilizarse para cada clave de API, eliminamos por completo los ataques de repetición. ¿Me estoy perdiendo algo?

authentication cryptography nonce

pregunta Dmitry Frank 18.05.2018 - 23:36

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication cryptography nonce

Cifrar un cuerpo en lugar de firmarlo (con JWT por ejemplo) ¿Está utilizando TSL / SSL para enviar / recibir correo electrónico igual que cifrar? [duplicar]

score 3 · Accepted Answer

El ataque de repetición es posible. Debido a que un atacante puede elegir su cuenta de cliente, solo puede elegir una entrada que un usuario legítimo haya elegido y volver a iniciar sesión.

Tenga en cuenta que, técnicamente, puede deshacerse del viaje de ida y vuelta adicional al elegir un nonce predecible como servidor nonce, como la hora actual y el nombre de usuario. Luego, almacena la última vez que lo usó el usuario y solo acepta nonces con un tiempo mayor para evitar la repetición. Si bien esto no es tan seguro como una fuente aleatoria, puede ser suficiente para algunos casos de uso.

Es decir, con este enfoque, es posible que tenga que implementar un período de gracia para los relojes, que no son precisos, y que acepte los elementos que están desactivados por algún tiempo. Un atacante puede obtener un token y usarlo dentro de este período de tiempo, donde no podría usarlo directamente, aunque esto es bastante improbable. Un atacante también puede obtener tokens para el futuro si puede manipular el reloj del cliente. Y posiblemente se puedan abrir otros vectores utilizando este enfoque.