Identificar cliente basado en hash computado

2

Actualmente estoy desarrollando una aplicación web que servirá datos a clientes de iPhone. Para ser el propietario de los datos, no quiero que otros clientes puedan obtenerlos.

Pensé que podría usar una clave secreta compartida entre el servidor y los clientes: una cadena codificada que incluiría la marca de tiempo para garantizar que uno de mis clientes haya realizado la solicitud. Entonces la solicitud se vería así:

http://domain.com/request/[desired_object_id]/[device_id]/[timestamp]/[hash]

Calcularía el hash como este en la aplicación:

hash = sha(desired_object_id + device_id + timetsamp + "mysecretkey")

Y en el lado del servidor, me aseguraré de que el hash se haya generado correctamente antes de enviar los datos. (todos los objetos identificados por "desired_object_id" están disponibles para todos los suscriptores). Como alternativa, también podría generar una clave aleatoria en lugar de una marca de tiempo.

El problema es que no me suena seguro ... Los datos no son críticos, es solo que no quiero ofrecer una API pública utilizada por no suscriptores. Y hacer esto también me impediría cambiar la clave secreta, porque esto obligaría a los usuarios a actualizar a una nueva versión del cliente (no es muy bueno para el negocio ...)

¿Hay algún otro problema conocido con esto? Hay una mejor manera de hacerlo ? Preferiblemente con la misma simplicidad.

    
pregunta Julien 09.04.2011 - 12:06
fuente

3 respuestas

5

Varios problemas aquí:

  1. Esta configuración obligaría a poner la clave secreta en el cliente. Cualquier persona con una habilidad de ingeniería inversa decente podría recuperarla y luego reproducir todas las solicitudes a voluntad.
  2. No tiene sentido poner cosas como 'desired_object_id y demás en el hash, si todas estas piezas son visibles en texto claro (la URL). La única razón para hacer esto es evitar que el atacante encuentre su clave secreta. Pero el método de prevención más sencillo aquí es simplemente elegir un buen secreto (de alta entropía).
  3. La marca de tiempo es la forma más débil de un nonce. Si necesita reproducir la marca de tiempo en el extremo del servidor, entonces está obligando a todos los clientes a tener relojes bien sincronizados. Si lo está utilizando simplemente por un nonce, entonces no está reconociendo una propiedad importante de los nonces: tienen que ser aleatorios. Las marcas de tiempo no son aleatorias, incluso si los relojes son descuidados, van a estar dentro de un día (86400 segundos por día), fuera de los 32 bits posibles (4.2 BILLONES de segundos), que utiliza una pequeña fracción del espacio de teclas posible , y ni siquiera está espaciado al azar, están agrupados en torno a un valor que casi conozco (hora actual).
respondido por el Marcin 09.04.2011 - 15:24
fuente
2

Lo primero es lo primero: su "cadena codificada" no puede ser secreta, porque cada instancia del cliente lo contiene, una presa fácil para ingeniería inversa . El atacante ya lo tiene. Un ejemplo famoso es la clave de cifrado de los contenidos de DVD, incorporada en algunos reproductores de software "autorizados" como PowerDVD ...

Entonces, lo que está buscando debe ser una cadena secreta por cliente , que puede ser una contraseña o un valor almacenado en una cookie en el cliente.

Luego, la respuesta fácil: use SSL (es decir, HTTPS ). Dentro de la solicitud, incruste la cadena secreta por cliente (esto ocurrirá automáticamente con una cookie); SSL se encarga del resto. En particular, SSL protegerá no solo la solicitud sino también los datos de las miradas indiscretas de los intrusos. No obtendrás nada comparable en términos de seguridad de ningún esquema local, independientemente de la cantidad de funciones hash y marcas de tiempo que incluyas en el guiso.

    
respondido por el Thomas Pornin 03.02.2013 - 16:32
fuente
0

Encontré un artículo interesante sobre stackoverflow , que describe diferentes maneras de hacer esto.

    
respondido por el Julien 13.04.2011 - 08:29
fuente

Lea otras preguntas en las etiquetas