Concern about an unresettable identifier within the time period

[akakou]

Problem

A web service might try to identify a user by having them generate and submit, over a short period of time or repeatedly, all the proofs they can produce within a given time window. The complete set of proof combinations a user could generate in that period could, in a sense, serve as a strong non-resettable identifier for that user during that time.

This abuse works as follows:

1. Set up an unresettable identifier
   a. The web service sets a user token in a cookie or a hidden form field as a weak identifier.
   b. The web service prompts users to generate $K$ proofs, where $K$ is the maximum number of proofs a user can generate within a single time window.
   c. The web service prompts users to send all proofs together with the token to the service.
   d. The web service verifies the $K$ proof.
   • If number of proofs is K and all proof are valid, service stores an “enabled” flag for the token.
   • Otherwise, it rejects the request and restarts the setup phase.
2. Authenticate using the unresettable identifier
   a. The web service requires users to include the token in every request:
   • If the service has the enabled flag for the token, it accepts the request.
   • Otherwise, it rejects the request and restarts the setup phase above.

The impact of this attack is that the service can obtain the token and proofs as an unresettable identifier, even though the PACT API produces multiple unlinkable sessions within a single time window. This is because users cannot generate additional proofs within that time window after completing the setup phase.

Proposal

To mitigate this attack vector, we could adopt countermeasures such as the following:

• The API should enforce rate limiting using only a short time window (e.g., 1 second to 1 minute) and avoid using a counter as same as this paper. (Also, the counter may be derived from whether the user is in private browsing mode, or it may increase only when the user resets cookies via the browser’s privacy settings.)
• The browser should require explicit user interaction to generate a proof (e.g., typing something), rather than merely showing a notification. In addition, the browser should require services to use a sufficiently large maximum counter limit so that users can clearly recognize abnormal usage.

[akakou]

Even if users have multiple counters rather than a single counter, PACT still limits the maximum number of proofs that can be generated to $K$, so this attack remains applicable.