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

Implements a rate limit for password resets #13934

Open
wants to merge 2 commits into
base: 3.x-dev
from

Conversation

Projects
None yet
5 participants
@sgiehl
Copy link
Member

sgiehl commented Jan 6, 2019

currently only prevents from requesting new password resets within one hour. Maybe we could even increase the time limit.

fixes #13813

@sgiehl sgiehl added the Needs Review label Jan 6, 2019

@fdellwing

This comment has been minimized.

Copy link
Contributor

fdellwing commented Jan 7, 2019

I would maybe change the limit to 2 per hour? There are valid reasons to try it a second time.

@sgiehl

This comment has been minimized.

Copy link
Member

sgiehl commented Jan 7, 2019

Are there? If sending the email fails on Matomo side the request get's removed again. So a new request can be done until the email was sent.

@fdellwing

This comment has been minimized.

Copy link
Contributor

fdellwing commented Jan 7, 2019

Mail might get not deliviered on recieving end for some spam or missconfiguring reasons (e.g. greylisting, missing forwarding, wrong trusted networks, etc).

@sgiehl

This comment has been minimized.

Copy link
Member

sgiehl commented Jan 7, 2019

Then it would make sense to allow resending the last request once instead of allowing a complete new one...

@fdellwing

This comment has been minimized.

Copy link
Contributor

fdellwing commented Jan 7, 2019

I currently don't see a difference, but that seems fine for me.

@sgiehl

This comment has been minimized.

Copy link
Member

sgiehl commented Jan 7, 2019

Requesting a new reset means filling out the form again and generating a new token for the reset. That means the email content is slightly another as the link differs

@fdellwing

This comment has been minimized.

Copy link
Contributor

fdellwing commented Jan 7, 2019

Ok, it's fine for me to send the exact same mail again.

@@ -36,6 +36,7 @@
"PasswordChanged": "Your password has been changed.",
"PasswordRepeat": "Password (repeat)",
"PasswordsDoNotMatch": "Passwords do not match.",
"PasswordResetAlreadySent": "A password reset was already requested shortly. If you have problems resetting your password, please contact you administrator for help.",

This comment has been minimized.

@tsteur

tsteur Jan 7, 2019

Member

Can you mention to try it again in an hour? (even though it might work again after 30 min but can be useful info)

@tsteur

This comment has been minimized.

Copy link
Member

tsteur commented Jan 7, 2019

I would have also allowed 2 or 3 per hour as it can be useful eg if mailbox is full etc but if it otherwise works within an hour again should be fine. Could have been also useful to block per IP but not needed (to avoid someone requesting forget password feature every hour for all users and basically blocking the feature, not really an issue though)

@sgiehl sgiehl force-pushed the pwdresetratelimit branch from 4672561 to 6c86af0 Jan 13, 2019

@sgiehl

This comment has been minimized.

Copy link
Member

sgiehl commented Jan 13, 2019

@tsteur Wondering what would be the userfriendliest and securest implementation.

  • Allowing to request a password reset only once an hour (e.g. an error will be shown when the last request was within the last 60 mins)
  • Limit the number of requests possible per day (or maybe month), without any "wait time" between the requests
  • Allowing to request a password reset only every 3-x hours, but show a message when another request is made within that time, that allows to trigger a resend of the last request (new token, but still the same password from the original request). Resending the request would also be limited to 2 or 3 times and afterwards an error would be shown to contact the admin
@tsteur

This comment has been minimized.

Copy link
Member

tsteur commented Jan 13, 2019

Ideally it would use the new brute force feature added in 3.8.0. We would add a new type column to the DB and methods to be able to take advantage of all the methods etc.

But it's a bit more work and #13813 is not even scheduled yet and not really important so would be too much work for now. I would probably simply allow 3 calls per hour for now or whatever is easiest.

@sgiehl

This comment has been minimized.

Copy link
Member

sgiehl commented Jan 14, 2019

@tsteur guess make sense to reuse that. This was just a quick approach to implement a simple rate limit. Maybe we should simply close this and implement it properly later?

@tsteur

This comment has been minimized.

Copy link
Member

tsteur commented Jan 14, 2019

No preference. Could also merge and just leave it like that. up to @Findus23 and @mattab

@Findus23

This comment has been minimized.

Copy link
Member

Findus23 commented Jan 14, 2019

This PR fixes the most important issue (you can endlessly spam users), so I would say this is good for now. And I wouldn't create a too complex logic as I still think that one day the password reset should be replaced with the "normal" way (#11071) and then there wouldn't be a difference between resending a reset and sending a new reset.

@mattab

This comment has been minimized.

Copy link
Member

mattab commented Jan 14, 2019

just a quick feedback: reckon it should be possible to request again the password reset in the hour. For example if the mailserver was buggy and email didn't get sent, or any other problem. 3 times per hour sounds good and would not be considered spammy?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment