My assumption is that resetting password is only a security issue if an attacker gained access to the user's email.

But I was wondering, what if someone simply abuses it (e.g. sends a "reset password" request every 5 second to an ex girlfriend/boyfriend email or a hated boss etc)

  • Is there a common practice to have some sort of count / time limit for password reset requests? (e.g. user can't ask to reset password more than x times in a period y)

  • Or is it considered a non issue as people don't really do that often? (or at least as often as people order pizza to someone else's address I assume)

*This is my first question here, I hope it follows the FAQ, please comment if its not

3 Answers 3


Yes, it is very likely that the same "excessive attempts" detection that is applied to login attempts is also applied to "password reset requests".

Many systems also involve a captcha step, that makes spamming the reset attempts more difficult. The example below is the outlook.com password reset page:

outlook.com password reset screenshot

I think this is a fairly inefficient attack - thanks to rate-limiting, it can't reliably target an individual, and even if it could, the emails could be trivially blocked with an email client rule.

  • Thanks for reminding me I need to throttle failed login attempts, which is whole other question
    – Eran Medan
    Commented Nov 21, 2012 at 1:44

You shouldn't make it possible to reset a password without some kind of (weak) user identification. This is important not only to protect against someone being a nuisance by repeatedly resetting the password, but also because it can be used as a form of short term DOS. The following is taken from Troy Hunt's great blog post on secure password reset:

One thing about each of the examples above is that the old password is only rendered useless after the account owner’s identity has been verified. This is very important as if the account could be reset before verifying identity and then the door is opened for all sorts of malicious activity.

Here’s an example: someone is bidding at an auction site and towards the end of the bidding process they lock out competing bidders by initiating the reset process thus removing their competition. Clearly there can be major adverse results if a poorly designed reset feature can be abused. Mind you, account lockouts by invalid login attempts is a similar story, but that’s one for another post.

As I mentioned earlier, allowing anonymous users the ability to reset anyone’s account simply by knowing their email address is a denial of service attack just waiting to happen. It may not be a DOS in the way we often think of it, but there’s no faster way to lock someone out of their account than though a poorly designed password reset feature.

Security questions are the most commonly used weak identification method. For more details on security questions please see the Wikipedia article.

  • 1
    I thought security questions are deprecated and discouraged (e.g. very easy to obtain using social engineering, or simply finding your trail in social networks, e.g. anyone can know someone's mother maiden name if they really want to find)
    – Eran Medan
    Commented Nov 21, 2012 at 7:45
  • Security questions are a very weak form of user identification and shouldn't be used in lieu of a password - i.e. you should never grant access to a resource based only on a security question. But security questions are probably good enough to prevent false password resetting (which isn't much of a hack - it's just a nuisance) and you can't do much better than them for this purpose. CAPTCHAs aren't very good for this purpose since the attack can be done manually (you only need to do it once an hour to be very annoying). Commented Nov 21, 2012 at 8:01

I am going to start with saying I have no idea if a best practice exists on this, but I will go ahead and answer with two points of view in mind; the security view and the user view...

First off, when a password request is made, the password should not be removed. What if you user all of a sudden remembered their password? They should be able to login without the reset request affecting their experience. Instead a onetime securely (lot's of entropy) generated random string should be generated and stored with the user as the last reset request identifier. A timestamp should be stored as well. Then the link that the user clicks on in the email should contain that ontime code and their email address in order to actually reset. You can also check the timestamp that was set to see if the request was made within the past 15-minutes or so (just an example). The other point in this is that if the person really didn't request it, they should still be able to log in.

Second, the best way to limit this is to use something like reCaptcha. It will get annoying for the user to constantly spam.

Third, I don't think it's necessary to ever send more than 2 emails within a specific time window.

I think the bigger security risk here is someone brute-forcing your forgot password page in order to discover account login information. Being able to detect that someone is bruce-forcing your "Forgot Password" page would be huge. Maybe recording the number of account reset requests from a specific IP address and watching for when that number gets too high in a certain amount of time and requiring the person to send an email to [email protected] in order get their account reset. [You will want to play with the numbers here because you need to consider people that sit behind NATs, notably employees at large corporations...you never know when everyone is going to forget their password on the same day].

  • Thanks, this is great and answers my question very well. I have some follow up questions that came up reading your answer: 1) why do I need to add the email on the reset link? is that to avoid brute guessing reset links? (not just need to guess a UUID, but also the related email) 2) is it really possible to brute force a UUID that has 1 hour expiration? is it statistically possible? (e.g. user issues millions of reset password requests for the same email and at the same time tries to guess a UUID that will match?
    – Eran Medan
    Commented Nov 21, 2012 at 1:22
  • To answer as follows: 1) The email is to keep you from having collisions mostly. If you using properly seeded UUIDs you shouldn't have an issue. 2) Statistically, no.
    – sparticvs
    Commented Nov 22, 2012 at 3:27
  • I know saying thanks is a newbie thing to do, but it's thanksgiving here, so Thanks!
    – Eran Medan
    Commented Nov 22, 2012 at 3:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .