¿Es este un método seguro para autenticar paquetes?

Navega tus respuestas
2

Tengo una arquitectura cliente / servidor que periódicamente envía paquetes UDP muy pequeños (de 10 o más bytes) de ida y vuelta, que me gustaría autenticar sin una gran sobrecarga en el ancho de banda o el procesamiento. Tenga en cuenta que no me importa que un adversario vea el texto simple, solo me gustaría evitar que modifiquen y retransmitan los paquetes.

Aquí está el proceso que estoy imaginando:

  1. El usuario se autentica con un nombre de usuario / contraseña a través de HTTPS. Nada fuera de lo común aquí.
  2. El servidor responde con un mensaje de éxito y N bytes (alrededor de 32 bytes) de datos aleatorios generados criptográficamente. Tanto el cliente como el servidor recuerdan esta cadena de datos como su common_secret .
  3. En este punto, la conexión HTTPS está cerrada y toda la comunicación posterior se realizará a través de pequeños paquetes UDP, utilizando este esquema para la autenticación:
  4. packet = plaintext + sha2(plaintext + common_secret)
  5. Al recibir un paquete, el servidor calculará el mismo sha2 a partir del texto sin formato y su common_secret , y verificará que coincida con el hash al final del paquete.

Un adversario no podrá construir un paquete válido sin conocer common_secret . ¿Es este un esquema de autenticación válido?

    
pregunta Joel 03.08.2016 - 17:57
fuente

3 respuestas

3

Vulnerabilidades en su método

Lo más probable es que su construcción sea vulnerable a un ataque de extensión de longitud que permite la modificación del mensaje, así como un ataque de repetición que permite reenviar mensajes enviados previamente.

Obligatorio: esta es la razón por la que no debería rodar su propio . En su lugar, use las soluciones existentes para los problemas que desea resolver.

Enfoques seguros

Una solución contra el primer problema es usar un HMAC adecuado. Si necesita protección contra ataques de reproducción, necesita intercambiar datos que no sean similares o similares.

    
respondido por el tim 03.08.2016 - 19:00
fuente
2

No, no es seguro. Como @ paj28 señala, hay ataques de repetición "obvios". Hay una razón para cada bit de sobrecarga en el modo de autenticación DTLS e IPsec. (Bueno, la mayoría del modo de autenticación de IPSec). Solo debes usar uno de ellos.

La misma lógica que lleva a "aquellos que no entienden TCP / IP están condenados a reinventarlo, mal" se aplica aquí.

    
respondido por el Adam Shostack 03.08.2016 - 19:00
fuente
0

su algoritmo parece que está intentando completar la integridad. Utilice un HMAC en su lugar para su firma. agregar un nonce requerirá que intercambies más nonces, lo que aumenta la complejidad de tener que intercambiarlos nuevamente.

tal vez use

HMAC con EPOCH

pero ahora debe asegurarse de que ambos relojes laterales estén sincronizados y continúe trabajando con DST si esto se aplica, la época obviamente solo le permite confirmar la actualización en x segundos, dependiendo de la latencia de su red.

así que quizás;

texto simple + HMAC (texto simple + época)

el hecho de que esté utilizando un HMAC significa que su secreto es ahora la clave para el HMAC.

como han dicho otros, inventar tu propio criptografía suele ser una mala idea.

¿por qué no firmar con cifrado asimétrico si está disponible para usted?

    
respondido por el Darragh 03.08.2016 - 21:07
fuente

Lea otras preguntas en las etiquetas

usando msfvenom para codificar un archivo exe sin ninguna carga útil, como el msfencode (empaquetado) Para 2FA, ¿es un método mejor (más seguro) que otro?