Would additional security risk and mitigation discussion be valuable?

[jmileham]

Hi, my team is implementing an idempotency system and I was curious if the authors would be interested in any contributions along any of the lines of the observations that we had during our build. Admittedly this stuff gets pretty deep in the weeds, but since this spec and surrounding discussion seem to consider the possibility of providing idempotency as a proxy service layer, it may be important to go into some of these details so that implementers think these details through carefully - the security of any service an idempotency system fronts will be impacted by the idempotency service's implementation decisions. These are admittedly defense-in-depth considerations, but if critical systems are (or could be in the future) involved, it seems maybe valuable.

1. Idempotency records: a. Online attack: with an exfiltrated idempotency key (and likely an authentication token), an attacker can retrieve the replay response of a previous legitimate request. To mitigate, we chose to expire and expunge old idempotency records, in alignment with the draft's Key Validity and Expiry policy. b. Offline attack: with a data breach of the idempotency service, the response data could be retrieved. To mitigate we would recommend encrypting the stored response payload if any data that might be returned in a response would indicate encryption under the deployer's security policies. c. Highly sensitive response data: Some highly sensitive response values may not be suited even for replay more than once, or encrypted storage (e.g. data that would normally be cryptographically hashed and then forgotten), so disabling the replay response mechanism (e.g. switching to 204 response) or disabling the idempotency system altogether may be appropriate for some use cases.

2. Idempotency Fingerprints: a. Online attack: with an exfiltrated idempotency key (and likely an authentication token), an attacker can attack the inputs of an idempotent request by detecting whether the service returns success or 4xx error. To mitigate, we chose to expire and expunge idempotency fingerprints aggressively based on both time and request count. b. Offline attack: with a data breach of the idempotency service, the request fingerprint could be retrieved and attacked offline, or hybrid online/offline with attacker-chosen payloads. To mitigate, we used HMAC with strong cryptographic hash functions to both individually salt the fingerprints (with a server-generated salt) and with a true HMAC secret that would not be disclosed in a database-only breach. c. Highly sensitive request payloads: With some inputs, such as user passwords, it may not be appropriate to store an HMAC digest at all, or distinguish between input payloads in responses. Disabling idempotency fingerprinting or disabling the idempotency system altogether may be appropriate for these use cases.

[Acconut]

1. a. Online attack: with an exfiltrated idempotency key (and likely an authentication token), an attacker can retrieve the replay response of a previous legitimate request. To mitigate, we chose to expire and expunge old idempotency records, in alignment with the draft's Key Validity and Expiry policy.

Can the idempotency fingerprint help making such an attack less likely? If the resource only replays the response if the idempotency key and fingerprint matches the entry in the idempotency service, then an attacker must not only possess the idempotency key, but also all other details of the original request which are fed into the fingerprint.

[jmileham]

Yes, it could! It would potentially come with the tradeoff of having to present a 4xx response to a user after a small-ish number of retrieval attempts instead of a more likely "success" response for a non-attacker with annoyingly bad network conditions.

You could also/alternatively take the view that the idempotency record online attack is really not very surprising/scary for a reasonably short (call it a week) retention window and not worth further mitigating. The attacker would have to have stolen the idempotency key and a still-valid auth token in order to mount the attack, at which point you'd likely believe they had full access to the browser history and cache of the target. We've taken the view that the oracle attack on the inputs (2.a.) is far more surprising than 1.a. Under 2.a., without sufficient mitigation, stealing somebody's laptop after they performed a sensitive operation would allow an attacker to infer information that was entered before the device was stolen and never even persisted on the device.

[jmileham]

Also in the context of a proxy idempotency service, there would have to be coordination with the underlying service about the authenticated identity of the client in order to protect against attacks on other users' inputs and outputs. Some ways to achieve this would be to have the idempotency service be the authentication service for the underlying service, or already be wrapped in an authentication service that converts the user ID into a header that the idempotency service is aware of, or wire the idempotency service into the same authentication service that the underlying service uses (making a call out to check auth tokens and confirm identity). It would be insufficient to trust a client-provided user ID.

This feels like a maybe substantially difficult capability to generalize given the profusion of different auth strategies in the wild, and maybe a barrier to adoption as a standalone service.