5 ms·
Per-User Rate Limiting
- the_arun 5y agoIf it is authenticated user, we could ratelimit by userid instead of IP. I’m assuming the article is talking about ratelimiting by anonymous user requests or static content.
- weird-eye-issue 5y agoYou should really attempt to understand what you are reading before you comment
- the_arun 5y agoI agree. Thank you for the suggestion
- beardyw 5y agoFor my own site, paranoid as I am, for logins I used to just return an empty login page whatever. Best security for maximum user frustration I'm sorry to say!
- waffle_maniac 5y agoWouldn't rate limiting via cookie be easy to get around by starting a new session with a new cookie. Or am I understanding this wrong?
- kevincox 5y agoI think you missed a key point. You need to separate the rate limiting key from the whole cookie. So for example if you want to rate limit by user ID you need to duplicate the user ID outside of the main session cookie so that the expiry date, session id, etc.. are not included in the rate limiting key. (Or teach the proxy to extract the key, which is possible for signed but not encrypted cookies.) The app then needs to verify that the "extracted" data is actually correct and trusted.
- tragictrash 5y agoThis isn't totally correct. The problem isn't the cookie itself, but rather the cookie's integrity isn't cryptographically verifiable. One could use a cryptographic signature set in the cookie to avoid tampering, using a HMAC or some other hashing function. We don't need or want to hide the Id and rate key from the user, we just need to verify the integrity of it.
- kevincox 5y agoYes, correct. However depending on the proxy/tool doing the rate limiting it may be easier to limit based on a key in a separate cookie or header than extracting from a signed cookie. Even if the other cookie or header is logically covered by that signature keeping it more separate may make it easier overall.