Seguridad para la API REST (usuario / pass auth vs hmac vs oauth)

14

Tengo dos servidores (uno en Hetzner (lo llamo H) y otro en mi oficina (llamándolo O)). Necesito ejecutar un servicio web básico de CRUD en O y el único consumidor del servicio es H. Los datos en O son datos confidenciales del usuario. Este es un servicio de cinta de cinta temporal que desaparecerá en el futuro junto con la necesidad del servidor O.

Esto es lo que tengo en mente:

  1. El servicio se ejecutará en https
  2. autenticación HTTP básica para autenticación de solicitud
  3. Abriendo el puerto en O solo para la ip de H a través de iptables.

¿Me gustaría saber si suena lo suficientemente seguro o si hay algo que pueda haber pasado por alto? ¿Existen ventajas que ofrezca HMAC o OAuth sobre este enfoque?

    
pregunta Abhinav Kaushik 30.07.2013 - 15:01
fuente

1 respuesta

15

HMAC es un algoritmo criptográfico que tiene sentido como parte de protocolos más grandes; No debes jugar con él directamente. Cuando utiliza HTTPS, la capa SSL en realidad incluye algunos HMAC (entre otros algoritmos).

OAuth es un estándar para autorización cuyo caso de uso principal es administrar la autenticación de los usuarios sin compartir credenciales: la idea es que un usuario podría tener credenciales (una gran palabra para "contraseña") en un solo servidor, que se puede usar para que varios otros servidores sin confiar en ellos suficiente para mostrarles la contraseña real. Por ejemplo, los servidores S y T confían en el servidor de autenticación A , el usuario U también confía en A suficiente para mostrar su contraseña (dentro de una conexión HTTPS), y S y T hablan con A para asegurarse de que el usuario U es en verdad quien dice ser; Lo bueno es que S y T nunca ven la contraseña y U no necesitan confiar en ellos .

En su caso, tiene un solo "usuario" (su servidor H ) y, dado que se trata de una máquina, no debe ser exigente con su contraseña; H puede tener una "contraseña" (una larga secuencia de caracteres aleatorios) que H usará solo para autenticarse con O , por lo que no hay necesidad de la complejidad adicional de OAuth.

La vulnerabilidad inherente aquí es que el servidor H tiene acceso a los datos confidenciales. Eso es por diseño, pero esto significa que los datos llegan a un servidor hospedado, lo que implica que confía en el servicio de hospedaje para no mirar sus datos o filtrarlos por descuido. No puedes evadir eso, según la definición de tu problema. Básicamente, usted considera que el servidor H es seguro, por sí solo, contra escuchas ilegales y alteraciones hostiles. En estas condiciones, la autenticación "Básica" de HTTP ejecutada dentro de HTTPS estará bien .

Es posible que desee ajustar la autenticación del servidor de bits: la máquina H deberá asegurarse de que habla con el servidor original O , que normalmente conlleva la validación del certificado. Puede configurar H para que la "confianza directa", es decir, importar en H una copia del certificado de O (solo el certificado público, no la clave privada), e indicando a H que confíe en ese certificado específico y en ningún otro. Esto puede evitar problemas con las Autoridades de certificación y, en particular, permite el uso seguro de certificados autofirmados, que son baratos (ya que no tiene que pagar a una CA por dicho certificado).

    
respondido por el Tom Leek 30.07.2013 - 15:17
fuente

Lea otras preguntas en las etiquetas