Debes considerar varios factores aquí. Espero que su clave API tenga un tiempo de expiración? Incluso si lo hace, es vulnerable a un ataque de repetición si un adversario se apodera de su solicitud HTTPS. Como remedio, puede introducir una marca de tiempo o un contador a su solicitud.
Ataques de repetición de contador
Se puede agregar una marca de tiempo al mensaje y cifrarse junto con el resto del contenido del mensaje. El servicio puede
recupera la marca de tiempo después de descifrar el mensaje y falla la solicitud si la marca de tiempo es demasiado antigua para el umbral
eso ya está acordado. Esto reduce la ventana de oportunidad para reproducir una solicitud. La desventaja de este enfoque es que tanto el servidor como el cliente deben estar sincronizados con el tiempo.
Una alternativa a una marca de tiempo es un contador. Con
un contador, no necesita preocuparse por el sesgo entre los relojes. Sin embargo, los clientes deben implementar un
contador para garantizar que el recuento enviado en una solicitud sea mayor que el recuento en la solicitud anterior al menos en uno, y el
El servidor debe mantener un registro del último contador recibido. Por supuesto, el mensaje debe ser firmado para que un usuario malintencionado
no incrementa el contador y repite el resto de la solicitud.
Código de autenticación de mensaje basado en hash para contrarrestar el ataque MITM
El mecanismo primario
para garantizar la integridad de los datos de los mensajes es un Código de autenticación de mensajes basado en Hash (HMAC). HMAC es solo una pieza
de datos creados a través de un algoritmo de hash criptográfico y una clave secreta compartida. Sin embargo, si el mensaje debe cifrarse por confidencialidad, puede agregar fácilmente esa funcionalidad
utilizando la misma clave privada que usamos para HMAC o puede introducir una nueva clave específicamente para el cifrado.
Cuando un usuario envía una solicitud, debe preocuparse por los siguientes tres parámetros importantes.
- La clave pública, que es la clave asociada con el usuario
- El contador
- La marca de tiempo
Además de los parámetros, la solicitud incluye una firma que garantiza que ninguno de los parámetros sea
manipulado. Es posible crear la firma basándose no solo en los tres parámetros, sino también en todo el cuerpo.
de la solicitud si el objetivo es asegurarse de que no se modifique nada en la solicitud.
Para asegurarnos de que nadie manipule los parámetros, podemos incluir un HMAC-SHA256 de los tres valores más el
solicitar URI y método HTTP.
Puedes introducir los siguientes 4 atributos en tu encabezado.
X-KEY
Esta es tu clave API
X-Signature
Si el valor enviado por la aplicación cliente en la X-Signature coincide con el HMAC-SHA256 del
Los valores de X-KEY, X-Counter, X-Stamp, URI de solicitud y el método HTTP, podemos concluir con seguridad
que nada fue alterado en tránsito.
X-Stamp
Se comparan el valor enviado por el cliente y la hora de UNIX de la hora actual. Si el
el sesgo entre estos dos está dentro del límite de tolerancia permitido, la solicitud no es una repetición.
La hora de UNIX es el número de segundos transcurridos desde la medianoche del 1 de enero de 1970 Coordinado
Tiempo Universal (UTC).
X-Counter
Si el valor enviado por el cliente es mayor que el último contador recibido en el registro mantenido por
El servidor, la solicitud no es una repetición. Aunque utilizo tanto la marca de tiempo como el contador en el
En el ejemplo de implementación de este capítulo, uno suele ser suficientemente bueno, dependiendo de su
necesariamente. Si los tiempos del reloj están razonablemente sincronizados, una marca de tiempo es el mejor enfoque porque no hay
gastos generales en términos de almacenar el contador en el lado de la API web o incrementarlo en el lado del cliente.
conclusión
Es mejor utilizar un marco de trabajo ya probado en batalla como OAuth para satisfacer sus necesidades. Pero si piensa que es demasiado complejo, debe considerar las cosas que se explican en esta respuesta.