I am working on a service which offers information on the road traffic situation.
Users can subscribe to the service via an API, indicating the area and road classes they are interested in, and are assigned a subscription ID. With the subscription ID they can then poll the service for information. The first poll will return any messages from that area, subsequent polls will only return messages that have been added, withdrawn or updated since the last poll operation. (Edit: All these operations are part of an app.)
Users also change their subscription at any time, i.e. change the area and/or road class; this will leave the subscription ID unchanged. They can also unsubscribe at any time. There is no operation for “show me what I have subscribed to”, other than by inferring that from message updates.
Users are generally anonymous, i.e. the system does not collect any user information and does not even have a mechanism to determine if two subscriptions were from the same user. Specifically, there are no user accounts (edit: other than the subscription ID, which can be seen as part of an ephemeral user ID). The expected use case is that users subscribe to traffic news when they start on a trip, change their subscription if they change their destination, and unsubscribe upon arrival. Thus, subscriptions “live” for anything from minutes to hours, but typically less than 24 hours. Edit: Session expiration is still TBD. For practical considerations, poll intervals could be as long as 15 minutes, but there might be longer periods of inactivity. For “forgotten” subscriptions, expiration intervals would likely be several hours after the last operation.
The scenario I am mostly worried about is ID guessing, i.e. an attacker trying a random subscription ID to poll the service and/or change subscriptions. For the attacker profile, this suggests a script kiddie: an individual with the skill level of an advanced user who thinks it’s fun to annoy random strangers.
As for protection requirements:
- Confidentiality: traffic messages are by definition public (anyone can see them), but a user’s subscription data (which can be inferred from the messages received) may disclose their whereabouts and travel plans, and as such is non-public. However, an attacker would need to take extra steps to identify the user.
- Availability: if messages are “lost”, the user will miss new traffic messages and end up in a traffic jam they had hoped to avoid, or taking a long detour to avoid a traffic jam which no longer exists.
- An attacker could unsubscribe a user (violating availability), though that would be apparent on the next poll: the service would reply “susbscription unknown” and the user could simply re-subscribe, at the cost of getting a full feed rather than a differential one (along with the related bandwidth usage).
- An attacker could poll the service: the related update feed would be delivered to the attacker (violating confidentiality) and the victim would not see the changes (violating availablility), unless the affected messages change again before the victim polls the service.
- An attacker could alter a user’s subscription: either to a much smaller area, which is equivalent to suppression of messages (confidentiality) but harder to detect than a rogue unsubscribe operation, or to the whole world, causing the user to be flooded with messages, consuming the user’s bandwidth and processing capacities. Depending on what the attacker has subscribed to, this may be much harder to detect than a rogue unsubscribe operation.
I would assume that the best defense here is to keep the IDs as random as possible (i.e. any two possible IDs are equally likely to occur) and above a certain length.
- How long would a subscription ID have to be in order to make guessing a valid (though random) subscription ID unfeasible for the kind of attacker profile I have in mind?
- Have I missed anything (that you would be able to name)?