Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Per-User Rate Limiting (kevincox.ca)
21 points by nalgeon on Jan 9, 2022 | hide | past | favorite | 8 comments


For 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!


Wouldn'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?


I 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.


This 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.


Yes, 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.


If 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.


You should really attempt to understand what you are reading before you comment


I agree. Thank you for the suggestion




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: