Stricter rate limit for login #4718
Conversation
Nutomic
requested review from
dessalines,
phiresky,
dullbananas and
SleeplessOne1917
as code owners
| .service( | ||
| // Handle /user/login separately to add the register() rate limiter | ||
| // TODO: pretty annoying way to apply rate limits for register and login, we should | ||
| // group them under a common path so that rate limit is only applied once (eg under /account). |
There was a problem hiding this comment.
Perhaps that path could be called /auth and only have signup and login under it?
There was a problem hiding this comment.
Or /account/auth, we can do that as part of #4428
|
I don't think it makes sense to group login and signup under the same rate limit. A lot of the current rate limits are overly broad, is there a downside to separating them? |
|
Adding another rate limit is possible, but much more complicated because it needs a db migration and then the setting also needs to be added to lemmy-ui. Generally I prefer sensible defaults for configuration, rather than countless tiny settings that need to be tuned to get the instance working well. |
|
This can be a problem for users who don't stay logged in for long periods of time (e.g. when a public/shared device is used) if the instance allows something like 7 registrations in 14 days. |
There was a problem hiding this comment.
I agree this specific rate limit could be a bit restrictive, but we can always add another one for the DB in the future. iirc there was another rate limit someone was requesting, but I'd have to look through the issues. Either way I'll make another issue for a login-specific rate limit.
Login only uses the
messagerate limit which allows a lot of requests, so an attacker can try to brute force it. Better to use theregisterrate limit which is much stricter.