solución HMAC para una API de descanso

Question

solución HMAC para una API de descanso

#1 de dst (6 votos)

8

Estoy tratando de aprender algunas cosas sobre las API de REST y uno de los temas que tengo problemas es la seguridad.

Estoy usando angularjs para la interfaz web y un marco delgado para la API php. He leído algunos artículos (me gustó este ) y comencé a implementar HMAC siguiendo este tutorial (no exactamente los mismos pasos). Me gustaría saber si hay alguna violación de seguridad importante en mi enfoque o si no lo estoy haciendo de la manera correcta.

Mientras uso AngularJS, sé que todo lo que almaceno en el lado del cliente no es seguro. Supongo que el usuario tiene una máquina "limpia como nueva" y sabe lo que está haciendo (probablemente sea el principal usuario de API). Mi mayor preocupación es el hombre en el medio y la replicación.

(En el lado del cliente)

El usuario ingresa su nombre de usuario y contraseña.
Su contraseña está encriptada (por ejemplo, sha256) y almacenada como global; (Su nombre de usuario solo se almacena en alguna parte)
En cada solicitud que la interfaz web envía a la api, se envía un hash hmac en el encabezado en el que se forma el mensaje usando el nombre de usuario, una marca de tiempo, la ruta al recurso, una cadena aleatoria (que tanto el servidor como el cliente es consciente; codificado) y la clave es el hash de la contraseña.

(En el lado del servidor)

Cuando el servidor recibe la solicitud:

Comprueba la marca de tiempo;
Comprueba si el nombre de usuario existe en la base de datos;
Intenta replicar el mismo hash hmac usando para el mensaje las variables (también recibidas en la solicitud) nombre de usuario, marca de tiempo, ruta al recurso y la cadena aleatoria (esta no se recibe en la solicitud; simplemente está codificada) . Para la clave, utiliza el valor almacenado en la base de datos que es la contraseña cifrada del usuario dado.

Si todas las validaciones van bien, el usuario debe ser un tipo de confianza y no solo un hombre en el medio.

man-in-the-middle rest hmac

pregunta Bruno Camarneiro 12.03.2014 - 13:58

fuente

1 respuesta

Lea otras preguntas en las etiquetas man-in-the-middle rest hmac

¿Cifrado de la base de datos o cifrado del sistema de archivos? Algoritmos de cifrado con un código de error para la contraseña incorrecta

score 6 · Accepted Answer

Veo varios problemas con su enfoque (sin ningún orden en particular, y muy probablemente no sea una lista completa):

Parece que está implementando la aplicación sin SSL / TLS. Si ese es el caso, no debe confiar en el lado del cliente, ya que un MITM puede reemplazar su implementación (segura) del lado del cliente con cualquier cosa que elija.

No hay forma de crear una aplicación web segura sin SSL, ya que el cliente cargaría su aplicación a través de un canal inseguro. Si su aplicación se implementa a través de un canal seguro (no está seguro de que angularjs admita la implementación sin conexión), ignórelo.

Si usa SSL, eso probablemente mitigará todos los demás escenarios de ataque, ya que protege contra MITM y los ataques de repetición. Lo único que podría ser un problema es la autenticación, dado que no utiliza certificados de cliente. Pero, por lo general, los tokens de sesión son suficientes para las aplicaciones web, ya que el servidor está debidamente autentificado (dado que se usa una implementación adecuada).
Desea protegerse contra los ataques de reproducción, pero solo use marcas de tiempo para las solicitudes. Si un atacante puede registrar y responder una solicitud lo suficientemente rápido, el servidor considerará que la solicitud es válida. Dependiendo de sus datos reales, esto puede o no ser un problema.

Para evitar ese ataque, agregue un contador de solicitudes o almacene la marca de tiempo de la última solicitud en el servidor (y requiera una marca de tiempo mayor que la almacenada).
Además de tu HMAC real, no estás enviando tus contraseñas , de esa manera un atacante con acceso a la base de datos Es fatal para su aplicación y las contraseñas de sus usuarios. Le recomiendo encarecidamente que elimine sus contraseñas.

Además, es una práctica habitual el hash de contraseñas muchas veces para aumentar la carga de trabajo requerida para los ataques de diccionario contra el hash.
Por lo que escribe, no está claro si incluyó el mensaje / contenido de solicitud en su HMAC. Pero supongo que es consciente del hecho de que un HMAC solo verifica la integridad de los datos con los que se genera.
No utiliza claves verdaderamente aleatorias para HMAC. Dado el poder de cómputo actual, es probable que las contraseñas débiles conduzcan a un HMAC que se pueda descifrar, ya que es posible calcular los posibles hash. Hashing múltiples rondas puede ayudar un poco (y sal en la sala de estar si el ataque es contra varios usuarios), pero es crucial que instales un poco de prevención de fuerza bruta al final (número máximo de solicitudes ilegales por hora o similar, luego bloquees la IP de origen).

Sin embargo, personalmente, nunca confiaría nada solo en base a las contraseñas de los usuarios.

Por lo tanto, personalmente, recomendaría no rodar su propio criptografía y quedarse con SSL / TLS. Si bien eso básicamente significa que todas las CA confiables para el cliente pueden certificar un MITM, creo que ese riesgo es mucho más bajo que un MITM que se certifica a sí mismo al entregar una aplicación web malintencionada, repitiendo solicitudes o descifrando el secreto del HMAC.