-
Notifications
You must be signed in to change notification settings - Fork 301
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
3 changed files
with
18 additions
and
3 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
5ce9e05
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is quite an old commit, but I'm interested in the security implications of adding an id to access tokens. My concern is in particular with the ability for an adversary to learn when users connect, if the id's are sequential.
For example, an attacker can make a script to request a new token each second: if the id increased by 1 since the last request, no one connected in the interval. If the id increased by more than one, one or more users connected in the interval. This can be automated to enable an adversary to track user activity on a site. Are there countermeasures in place? Wouldn't random id's have the same performance benefits, without the security drawback?
I would appreciate any insights about this.