I have a user that is being attacked by someone or a script hitting the forgot_password end point many times a day using their e-mail address. This has been happening for several days. Since this sends e-mail, it is also potentially abusive to the system. From the nginx access.log, I have tracked the IP address for some of this time to another user on the system and sent a warning message, but that might not help. I have also added this IP address to Admin > Logs > Screened IPs; however, I am not certain what that will do except prevent login temporarily. The IP address can and has changed, and it is probably a dynamic address but also someone could switch on a VPN and start again.
Does anyone have a suggestion on how to handle this?
Hi Dan, A couple of questions first if you donât mind.
Have you suspended the user?
Do you allow anyone to create an account or do you approve all new accounts?
You can suspend the user by going to admin/users/list/active and clicking on the offending userâs name. Once on his/her information page, scroll down to Permissions and click Suspend. Make sure the user is logged out because the suspension may not take hold until after they log out. If they are still logged in, at the top right of this same page is a blue box to log them out yourself. Once theyâre logged out, they cannot log back in using their old credentials.
If you approve new accounts - and the âculpritâ continues with his/her offense (and you are positive who it is) - the user will have to wait for you to approve the account. Since you already have one (or more?) IP addresses heâs used, if a new user shows up with that IP, you know what to do.
You can also visit the userâs preferences and under Account, view their recently used devices which should also give the IP address(s) theyâve used to log in with. That may give you additional IPs to screen.
This is where accounts needing to be approved comes in handy.
How is this person accessing the other userâs profile to request a password reset in the first place? Thatâs the important question.
Obviously, this search does not weed out the legitimate requests. I manually reviewed today and yesterday and saw a few legitimate requests (not on the repeated IP address). The vast majority are with a repeated IP address that changes every few days. It is not very bad on the system, but it is on the receiving user. I think the only thing I can do is setup nginx to deny by IP address, but with it changing⌠maybe if I check and update it manually for a week or two the person will stop trying but probably only for a little while. The victim says this initially happened to him about 1.5 years ago.
Itâs definitely annoying if someone decides to trigger the âforgot passwordâ over and over on your behalf ⌠but we canât lock the user out of password resets based on this, because locking someone out of password resets is also a form of griefing.
I believe we have a rate limit here on the order of multiple times per minute, can you review this code path @riking and confirm thatâs still functioning? We could increase it but that canât safely cover âa few times a dayâ.
Also, banning an IP address via Admin, Logs, Screened IPs should prevent that IP address from issuing a password reset, I think, and we should also verify thatâs working as expected @riking.
There is no option to not get an email sent to me for a password reset although I have 2FA on with reset keys.
Some websites Iâve visited show your IP address before you even ask for a password reset stating that it will be sent to your email.
All of this is a very minor nuisance as I rarely check this email for anything. All of the emails are filtered and set for âmark message as readâ so they donât appear that I have to read them. I set the filter up in January and just looked at the folder (Label in Gmail) today.
The image I couldnât include in the 1st reply.
When Gmail receives more than one message of the same subject, they group them.
Iâm guessing after 100 of the same, they just move on to the next 100 messages.
We can rate limit the requests for a particular user in addition to requests from a particular place (a limit which we can see working quite well right now). Maybe give people up to 2 non-expired reset tokens before we say âplease just wait for the emailâ?
Another approach can be to time limit the password reset emails to e.g. 3 Hours between tokens
Where, if a Password Reset email is requested before the cooldown period, a simple message can be displayed:
âWeâve already sent a password reset email, please check your inbox. If the email doesnât arrive in the next 2 hours, contact site admin for help on %contact_email%â
I changed the email in the forum to âemail+something@gmail.comâ, and I tested with Incognito on a different browser. Still got through. Perhaps because the request is always made with just the from username, and never with the actual email address.
For right now all of the fake requests have stopped since Dan must have addressed the issue either in private with the individual or by some other means.
If you had a security question option (to be activated at the user level) Iâm sure that would cut down on all requests as the troll simply wouldnât know the answer. âWhat is your favorite movie?â or âFavorite Restaurantâ.
Thank you all for your quick responses in trying to solve this issue, which sadly sounds like the first, and hopefully will be the last.
Is there a way to offer one or two âfreebieâ resets first, before forcing exact type, within a certain amount of time? Or perhaps adding exact type to an individual account only after so many resets, but automatically globally?
Some of us literally have no idea what day it is, much less remember without fail our exact email easily.
@Chinaski, I hope this is resolved quickly and finally for you.
Thank you everyone for responding. I hope the above works as it seems most direct remedy at this time, but I have not tested it since the pestering has subsided. (The potential attacking user says he tuned off guest on his WiFi, but we cannot be certain if that was the source.)
At thousands of active users, (we are still in the process of migrating to Discourse), I feel your pain. This comes up so much, with people forgeting what email they used and such, this has easily been one of our highest support requests over the years, itâs crazy.
I tightened the rules so worst case scenario a user can only get 6 resets a day. That should limit the emails to a degree.
I also followed @rikingâs advice here and we respect screened emails, so if you block an IP as an admin that IP can not participate in this party anymore.
One big omission here @riking which can assist self medication a bit is that the âpassword resetâ email does not include the IP address of the person that initiated it:
@codinghorror how do you feel about adding the IP address of the initiator in the set password emails (we could even hide it a bit), it will allow much better self medication.
Jane gets attacked
Jane notifies site admin that 12.12.12.12 keeps resetting passwords
Admin blocks 12.12.12.12
People do have access to lots of IPs so this can still be cat and mouse, but at least it is better than it was and the limits are tighter.
Facebook use this trick, which I kind of support implementing:
It allows them to avoid including IP addresses in the Email, they just track it server side and the link contains an id in the database. So this means it can become a 1 click kind of operation to block an abuser.
For context facebook require email for password reset (they donât even have password reset in a traditional sense, it is simply login via email)
I went through 100 of the fake requests and found a pattern, possible usage of a script.
This pattern is consistent throughout the 100 fake requests in one grouping in Gmail.
How is this person accessing the other userâs profile to request a password reset in the first place? Thatâs the important question.
