Forgot_password abuse

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.

  1. Have you suspended the user?
  2. 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. :wink:
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.

:thinking: How is this person accessing the other user’s profile to request a password reset in the first place? That’s the important question.


By visiting the forgot password page and entering their email address. Anyone can do it for any user.


Exactly how many times per day?


OK, “many” is relative.

root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.1
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.2.gz
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.3.gz
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.4.gz
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.5.gz
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.6.gz
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.7.gz
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.8.gz
gzip: access.log.8.gz: No such file or directory
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.9.gz 
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.10.gz 
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.11.gz 
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.12.gz 
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.13.gz 
root@forum-app:/var/log/nginx# zgrep -c forgot_password access.log.14.gz 

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. :thinking:

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.


I’m the one getting spammed with fake requests.
It happens multiple times per hour

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.


Good info. Let’s make some progress on this tomorrow @riking


Simple workaround you have, change your email from to

The emails from Discourse will route to your usual gmail but nobody will be able to send you forgot passwords, nobody can guess a secure hash.

I think, practically, this is the best thing to do in this case.

We could rate limit this down all the way to once a week and it would still be annoying. By using + addressing you will completely erase your problem.


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 ‘’, 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.


I guess the problem is that you can just crawl a forum for usernames and then troll a forgot password storm

Maybe we add a mode where you must type the email exactly to get the forgot password, forgot password strict, default off?

I feel like even being trolled once a week is too much, we can not rate limit ourselves out of this one


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? :thinking:

Some of us literally have no idea what day it is, much less remember without fail our exact email easily.

:crossed_fingers: @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.


Requiring email entry for forgot password will certainly never be a default on kind of thing.

But if a forum is under siege like in the OPs case, it could be a simple switch you would turn on for a few weeks to get this annoying hack killed.



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 keeps resetting passwords
Admin blocks

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.