Reset password - should I prevent abusing it?

Question

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}

Answer 1

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:

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.

Answer 2

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.

Answer 3

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].