Closed matrixbot closed 1 week ago
This comment was originally posted by @H-Shay at https://github.com/matrix-org/matrix-authentication-service/issues/2541#issuecomment-2243710950.
Rate limiting isn't my area of expertise but my first instinct is to look at what Synapse currently does and use that as a baseline:
It looks like the algorithm used is "leaky bucket as a meter" (https://github.com/element-hq/synapse/blob/d221512498f7e3267916a289dd2ef4f3e00728e8/synapse/api/ratelimiting.py#L40)
As for keys, synapse rate limits against several keys: ip address, account, and failed attempts. The rate limits are configurable and the defaults are:
address:
per_second: 0.15
burst_count: 5
account:
per_second: 0.18
burst_count: 4
failed_attempts:
per_second: 0.19
burst_count: 7
These limits are in-process/non-persistent, and from what I can glean from the code the rate limits appear to be applied per worker, but I would just double-check in the backend room that I am not mistaken about that.
As for config options, the ones listed above are the only ones I see related to rate limiting logins - I also don't see any options related to ignoring ip ranges for login (although there are ip block/allowlists for federation and url previews), I wonder if traditionally that has been handled by the load balancer or something similar. I'd also definitely ask in the security lobby if they have any insight on this issue - I am not sure how much the MAS usecase differs from Synapse, but I suspect they might have more insight/thoughs on this.
This comment was originally posted by @davidegirardi at https://github.com/matrix-org/matrix-authentication-service/issues/2541#issuecomment-2250427998.
I'd take some inspiration from https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks and then here are some suggestions:
This comment was originally posted by @sandhose at https://github.com/matrix-org/matrix-authentication-service/issues/2541#issuecomment-2250796957.
Thanks both for the input! I had a first shot at it in #3013
I'm using the governor
crate, which uses the Generic Cell Rate Algorithm.
With that PR, the quotas are hard-coded (I'll introduce configuration in another PR), and I only did logins for now.
For logins, I'm keeping two rate limiting buckets:
per_second=0.05 burst_count=3
)per_second=0.5 burst_count=1800
)(…writing this, it feels obvious that I need to tweak those numbers 😅)
The state is in-process, checked server-side, and shouldn't cost much, as governor looks quite efficient
I don't distinguish failed attempts, because the library doesn't let me 'test' the rate limiter without consuming a cell
This comment was originally posted by @davidegirardi at https://github.com/matrix-org/matrix-authentication-service/issues/2541#issuecomment-2255698747.
Unless those limits just count the failed attempts, I'd relax the one per IP address quite a bit, for example if a company has just one public IP for lots of employees, or a library or a school. per_second=10 burst_count=50
.
For the second one, I'd go much more aggressive instead: per_second=0.2, bust_count=3
.
This issue was originally created by @sandhose at https://github.com/matrix-org/matrix-authentication-service/issues/2541.
Questions to answer: