¿Proteger contra un cliente malintencionado con la función de derivación de claves (PBKDF2)?

0

Considere un protocolo que permita a los clientes recuperar "formularios" XML desde un servidor. Los formularios se identifican mediante un ID de formulario único, generado aleatoriamente, que está incrustado en el formulario. Los clientes completan el formulario y lo envían al servidor, la comunicación utiliza solicitudes de SOAP relativamente simples que contienen el formulario en el elemento del cuerpo de SOAP.

Tengo la tarea de implementar el lado del servidor en este escenario. Mi problema es con clientes malintencionados que pueden manipular el ID de formulario incorporado (cambiarlo a algún valor arbitrario) y enviar dicho formulario al servidor. En el lado del servidor, es posible que ya exista un formulario con el ID de formulario modificado que se sobrescribiría con el envío, lo que provocaría una pérdida de datos.

Mi solución propuesta sería incrustar un hash PBKDF2 del ID de formulario junto con el ID de formulario de texto sin formato. Si el cliente manipula la identificación simple o con hash, el servidor rechazará el envío. ¿Es esta una forma razonablemente segura de garantizar la integridad de la forma? ¿Es un problema divulgar el hash al cliente en este escenario (estamos hablando de integridad de datos aquí, no de confidencialidad)? ¿Hay algún problema potencial con mi solución (por ejemplo, usar un mejor método de derivación de claves)?

Cualquier ayuda es apreciada!

    
pregunta Michael Schmid 19.09.2014 - 11:34
fuente

2 respuestas

1

Si la sal utilizada para PBKDF2 es de una longitud no trivial, digamos 128 bits, y la sal se almacena con el ID de formulario en el servidor (solo), esto le permitirá verificar si el ID de formulario ha sido manipulado. con. Debe haber un componente secreto del hash debido al principio de Kerckhoffs , también conocido como la máxima de Shannon. En este caso, la sal, almacenada solo en el servidor, es el secreto.

    
respondido por el Bob Brown 19.09.2014 - 17:00
fuente
1

Parece que tu problema podría resolverse con tokens anti-CSRF o quizás ya los tengas en otro lugar. Vea el enlace de abajo para más detalles. Básicamente, con cada solicitud de formulario, el servidor enviará y validará un token único. Si el token no es válido, se bloquea la solicitud. El token sería único, válido solo para esa solicitud, y un usuario malintencionado tendría dificultades para reproducir el token. Los usuarios malintencionados podrían manipular lo que quieran en el formulario, sin ese token no importa.

enlace

    
respondido por el Paraplastic2 19.09.2014 - 21:10
fuente

Lea otras preguntas en las etiquetas