You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 12, 2023. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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.
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
andfillRate
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.
The text was updated successfully, but these errors were encountered: