Skip to content
This repository has been archived by the owner on Jul 12, 2023. It is now read-only.

Abuse detection and prevention #534

Closed
6 of 7 tasks
sethvargo opened this issue Sep 11, 2020 · 3 comments · Fixed by #571
Closed
6 of 7 tasks

Abuse detection and prevention #534

sethvargo opened this issue Sep 11, 2020 · 3 comments · Fixed by #571
Assignees

Comments

@sethvargo
Copy link
Member

sethvargo commented Sep 11, 2020

TL;DR

We need a way to prevent a leaked API key or leaked user credential from providing codes to verify too many TEK uploads.

Leaked user credentials is largely mitigated by requiring MFA. For ENX, we should require MFA. Leaked API keys are currently mitigated by rate limiting, but we'd like a more intelligent system.

Proposal

  • Update go-limiter and go-redisstore to allow for bucket-level configuration. Right now, maxMokens and fillRate are properties of the limiter; we need to make them properties of the key. This will enable individual keys to have a different limit.

  • We'll keep existing mitigations and rate limiters in place. This new limiter will only be checked after the preliminary APIKey/userID/IP based limiter. We'll only attempt to "take" from this new limiter right before a successful code issue. If successful, continue. On failure, return a well-communicated error message and error code (if called via the API).

  • Provide a realm-level configuration for allowed growth factor. This is a float value and is used to calculate the maximum number of codes the realm can generate in a 24h period. The total number of allowed daily codes is a polynomial calculation over all known data for the realm multiplied by this growth factor.

  • Provide some sane base value. This would be the min and default value for a new realm. Starting at 10 for now.

  • Run a new daily job (or use the cleanup job) each day at 12:00 UTC to recalculate, update the buckets, reset the counters, etc.

  • Set up monitoring and alerting when realms are at certain capacity levels (e.g. 90%). These will have to go to the server operators since we don't have a way to send email to realm admins. (input wanted)

  • Realm admins can bump the quota by either increasing the growth factor or disabling the quota for a period of time.

@sethvargo
Copy link
Member Author

/cc @mikehelmick

@sethvargo sethvargo self-assigned this Sep 14, 2020
@jeremyfaller
Copy link
Contributor

MAX(codes_in_the_past_7d) * growthrate = 0 if no tokens in last 7 days. This is a startup problem, and 1.5 is a problem if we have spikes from things like Sturgis or other large public gatherings in jurisdictions with small outbreaks to begin with (eg Maine weddings). I would suggest >= 10 as a factor if we go with constant*MAX approach.

Is it possible we can get a good approximation of the constant based on the R-factor of the disease's growth in a region? That seems like a good way to give guidance for admins.

@sethvargo
Copy link
Member Author

Yea, I'm gonna switch to a polynomial distribution instead.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants