¿Desea responder con un libro de Tan?

Question

¿Desea responder con un libro de Tan?

#1 de GreatSeaSpider (2 votos)

3

estoy intentando asegurar una conexión entre un dispositivo móvil (cliente) mediante una aplicación web y un dispositivo doméstico (servidor) en una red Wifi potencialmente insegura.

La comunicación es asíncrona y estoy tratando de evitar " ataques de repetición ".

Estaba pensando en la Respuesta de desafío, pero la sobrecarga de " pedir desafío, recibir desafío, enviar mensaje con desafío resuelto " es un problema de rendimiento para nosotros.

Así que estaba pensando en utilizar algún tipo de TAN El enfoque del libro, como el horneado en línea, lo hace:

Inicialmente, el Cliente solicitaría un conjunto de Desafíos que almacena. El Servidor almacenará esos Desafíos y hará un seguimiento de cuántos ya se están utilizando.

Si solo quedan n Desafíos, el Servidor crea nuevos Desafíos y los envía con la siguiente respuesta al Cliente. De esta manera, el Cliente casi siempre debería tener suficientes Desafíos sin la sobrecarga de Preguntarlos primero antes de cada solicitud.

Ejemplo:

El cliente desea iniciar sesión y solicita los desafíos primero, dando su nombre de usuario / ID de usuario.
El servidor crea n Desafíos y los almacena para el ID de usuario dado, luego los envía al usuario.
El cliente envía la identificación de desafío y el hash (desafío, secreto compartido).
El servidor compara el desafío almacenado (identificado por challenge-id) con secreto compartido y, si es correcto, devuelve el éxito y elimina el desafío desde que se usó.

entonces se vuelve más fácil

El cliente desea llamar a API Endpoint X en el servidor, envía una solicitud con encabezados agregados (challenge-id, hash (challenge, shared-secret))
El servidor comprueba el desafío y el éxito de uppon lo elimina, ejecuta el método x y devuelve la respuesta. En respuesta, agrega un nuevo desafío en el encabezado ( es decir, challenge_id-xyz: 45egrgh3gw43gw43zrezh54egh44zg54b54esb ... 54sreh5j )

si el cliente tiene pocos desafíos

El cliente desea llamar a API Point X, envía una solicitud con desafío en el encabezado
El servidor revisa el Desafío, luego de que lo elimina, se da cuenta de que el cliente tiene pocos desafíos (debido a la baja cantidad de desafíos almacenados) y crea otros nuevos. Envía Response for API Point X y agrega nuevos desafíos en los encabezados.

¿Ya existe un concepto como este y, si no, suena muy parecido a " hornear tu propio cripto " o suena legítimo? ¿O hay una mejor manera de hacerlo sin una gran sobrecarga de http?

authentication replay-detection

pregunta Andresch Serj 26.02.2015 - 10:54

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication replay-detection

¿Cómo puedo agregar módulos a una carga útil en Metasploit? ¿Cuál es el mejor antídoto para el envenenamiento de caché de DNS?

score 2 · Answer 1

Bueno, respondiendo a tu pregunta sobre si hay una mejor manera de hacerlo, me pregunto si una solución un poco más simple que he usado anteriormente podría estar a la altura de la tarea.

En lugar de generar una lista predefinida de desafíos y transmitirlos, haga que el cliente y el servidor agreguen un valor incremental predecible al hash que pasa en el encabezado. Tanto el cliente como el servidor cuentan la cantidad de llamadas / respuestas para la sesión y pueden rechazar cualquier hash recibido (reutilizado). El valor incremental puede ser tan simple como un conteo, o podría ser alguna función matemática simple realizada en el conteo si te sientes particularmente paranoico.

Se vería algo como esto:

El cliente desea iniciar sesión y envía una solicitud de inicio de sesión con userid & hash (una combinación sensata de secreto compartido con ID de usuario o alguna tal).
El servidor examina el hash y, si es correcto, devuelve el éxito y un token de sesión.

Ahora para cada llamada hecha:

El cliente llama al punto final de la API X en el servidor, con un hash de encabezado agregado (token de sesión, valor incremental)
El servidor verifica que el hash coincida con el token de sesión & el siguiente valor incremental esperado para esta sesión, si lo hace, envía la respuesta del punto final también firmada con hash (token de sesión, siguiente valor incremental).
El cliente verifica que el encabezado de respuesta contiene un hash del token de sesión y el siguiente valor incremental que esperaba.

y repita.

Si alguna solicitud / respuesta llega con un hash reutilizado en el encabezado, el valor incremental estará fuera de secuencia y el cliente / servidor puede rechazarlo. Tampoco hay que preocuparse por generar, transmitir y mantener una lista de desafíos para la sesión.

Las desventajas aquí involucran problemas causados por hacer múltiples llamadas y que se salen de la secuencia debido a problemas de red o al diseño / requisitos de la aplicación. Las formas en torno a esto implican agregar un punto central al cliente para ordenar / poner en cola todas las solicitudes y respuestas para la sesión, o alternativamente crear una sesión separada para cada hilo o conversación dentro de la aplicación cliente. Tal vez sea una consideración adicional durante el desarrollo, pero si el requisito de mantener el tráfico al mínimo es lo suficientemente importante, tal vez valga la pena el esfuerzo.

Los comentarios y pensamientos son muy bienvenidos.