Asegúrese de que el mensaje firmado no se pueda reutilizar a través del chat IRC

2

Quiero enviar "mensajes administrativos" a través de un chat IRC. Por ejemplo, quiero poder dar puntos a una persona durante una animación y todos pueden verlo en su interfaz de usuario porque puedo cambiar su cliente web.

Dado que firmo un mensaje con una clave RSA, las personas pueden asegurarse de emitir el mensaje por primera vez. Sin embargo, me gustaría evitar que las personas reutilicen mi mensaje firmado.

Varios problemas que pensé:

  • Simplemente podría agregar una marca de tiempo a los clientes, pero podría haber errores de sincronización y el mensaje se puede reutilizar si es lo suficientemente rápido
  • Podría guardar en caché los mensajes que emití para que no se puedan reutilizar nuevamente, pero las personas pueden desconectarse y luego regresar y habrían perdido los mensajes, el mismo problema es cierto para los números de secuencia.
  • Podría usar respuestas de desafío, pero la red es bastante lenta y enviar un mensaje a un puñado de clientes podría ralentizar mis propios mensajes.

¿Hay alguna manera de hacer esto?

    
pregunta Cydonia7 14.05.2017 - 23:52
fuente

2 respuestas

1

Hay cuatro enfoques principales para este tipo de problema, que se pueden combinar para obtener propiedades de seguridad más deseables.

  • Almacena en caché los mensajes recibidos. En este enfoque mantendrás una lista (de los hashes) de todos los mensajes recibidos. Si encuentra un mensaje en dicha lista, lo descarta como una repetición. El problema obvio aquí es la cantidad de almacenamiento necesario.
  • Usar sellos de tiempo / vencimiento. En este enfoque, agrega un sello de tiempo / una ventana de tiempo o un tiempo de vencimiento a sus mensajes. Si se reciben fuera de la ventana acordada, se descartan. La desventaja aquí es que si el atacante es lo suficientemente rápido, aún puede repetir y usted necesita tener un reloj confiable. Esto se puede combinar efectivamente con el primer enfoque.
  • Use números de secuencia. En este enfoque, agregará un número de secuencia a sus mensajes. Los mensajes se descartan si su número de secuencia es inferior al valor esperado. La desventaja obvia es que se requiere sincronización de estado.
  • Usar desafío-respuesta. En este enfoque, el cliente envía un desafío impredecible al servidor, el servidor incluye este desafío en el mensaje y el cliente mantiene el desafío en la lista blanca. Tan pronto como se recibe una respuesta pendiente a un desafío abierto, el mensaje se acepta como válido. Tan pronto como se acepta un desafío válido, el desafío ya no debe considerarse válido para uso futuro (es decir, descartado). La desventaja obvia de esto es que las partes deben estar en línea, es decir, intercambiar mensajes de manera algo simétrica y de manera oportuna.

Para su sistema, parece que la sincronización mínima de los dos primeros enfoques ofrece lo que necesita.
TLS utiliza el tercer enfoque para el transporte de datos en masa y algo así como el último para el protocolo de enlace.

    
respondido por el SEJPM 05.06.2017 - 21:39
fuente
0

No estoy seguro, pero estoy pensando que tal vez haya un problema XY en esta pregunta.

Esta es mi suposición sobre tu situación:

  1. El navegador del usuario intenta acceder a una función de aplicación restringida
  2. La aplicación envía el navegador al sitio web de identidad para obtener un artefacto o token de portador que contiene el permiso necesario para usar la función restringida
  3. El sitio web de identidad comprueba la identidad del usuario, genera un artefacto que indica que los permisos son correctos para la operación, lo firma y lo devuelve al navegador
  4. El navegador accede a la función restringida, pero esta vez con el token que indica que el usuario tiene los permisos necesarios.
  5. La aplicación lee el token y realiza la operación.

En este caso, le preocupa que el token de portador, que fluye a través de Internet al navegador del usuario, pueda ser reemplazado por un token de portador obtenido anteriormente, para un usuario diferente que pueda tener más permisos.

Sin embargo, no debes evitar completamente la reproducción. Por ejemplo, si el paso 4 falla debido a un problema de red, el usuario debería poder actualizar la página y volver a intentarlo, y el mismo token se enviará nuevamente. Esto está perfectamente bien.

Lo que sí desea evitar es que el usuario envíe un token / artifact de otro usuario. O si los permisos del usuario fueron revocados hace un día, no desea que el usuario envíe su propio token desde hace dos días.

Todo lo que necesitas para esto es asegurarte

  1. El artefacto identifica al usuario
  2. El artefacto identifica el permiso
  3. El artefacto indica un período durante el cual se concede el permiso al usuario
  4. El artefacto se firma de una manera que puede validarse

Si hace todo lo anterior, no es necesario bloquear la reproducción. Bueno, técnicamente el artículo # 3 anterior incluye un intervalo de fechas, por lo que es una especie de mitigación de repetición débil. Pero la idea de que cada token debe generarse en el contexto de un desafío aleatorio y una respuesta no es correcta: el servidor de identidad solo tiene que indicar ("afirmar") que un usuario, un permiso y una ventana de tiempo deben estar todos juntos y firmarlo . Si lo hace, evitará el tipo de ataques que creo que le preocupan.

Por favor, corríjame si mis conjeturas son incorrectas.

    
respondido por el John Wu 06.06.2017 - 01:47
fuente

Lea otras preguntas en las etiquetas