-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rate Limit Authenticate and Reset Password Requests #69
Comments
A PR with good tests would be favorably considered. |
Probably it should be feature of main feathers for any service |
I can't be everywhere. A PR is welcome. |
IMHO this is typically a task to be tackled using an external tool such as a reverse proxy like traefik.io. However I must confess it is still hard to easily find something that works natively with web sockets. |
Thanks Luc. I think we can close this now. |
@claustres if you do that using traefik it will work for WS trafick or only HTTPS? Any advice? |
Yes as far as I know traefik will only handle HTTPS since it does not know what information is on the wire with websockets. I have written something about that in Medium since I commented here: https://blog.feathersjs.com/feathersjs-in-production-password-policy-and-rate-limiting-32c9874dc563. It is a more general approach that does not require to manage this at module level. |
any updates on this? I have a public API that sends an SMS and does some database calls. Rate limiting it would be really great |
I don't think that rate limiting should be part of this package. First of all, DOS attacks could/should be prevented on network/firewall level, not within the application. And second, rate limiting of login attempts/password resets can be accomplished with some lines in a hook (see here a Gist of mine) or using the more general approach described by @claustres (see above). |
Authentication requests are using bcrypt which uses a lot of CPU. This means someone could make several authentication requests and possibly earn a denial of service attack.
I suggest throttling how many reset password, login, sign up, and change password requests can be made in a period. Perhaps we allow 3 upfront, then for each consecutive one they must wait 5 minutes. I suppose we can set the limits based on ip address.
The text was updated successfully, but these errors were encountered: