HappyDeveloper
HappyDeveloper

Reputation: 12805

How to protect a reset password feature?

I want to implement a reset password feature in case users lose their passwords. But I'm worried about someone being able to make a lot of these requests for a single or multiple email addresses that don't belong to him, which would be annoying for the actual owners of those addresses, and I would end up blacklisted.

What can I do to secure this feature against that? Set a limit of valid emails sent per ip? (3 emails max would be fine I guess)

Upvotes: 3

Views: 5196

Answers (5)

Basil Musa
Basil Musa

Reputation: 8738

Forgot Password Page Protection:

  • Show a success message when an invalid email is entered. When someone enters an invalid email, tell the user that the reset password link has been sent to your email (but dont actually make the code do anything). This will protect from hackers trying to identify valid accounts on the system.

  • Use A Captcha Phrase. To avoid malicious scripts from triggering many reset password requests for a large list of emails.

  • Reset password link for a specific email should not be sent more than 3 times (or so) per hour. This will protect from flooding the database with too many reset links stored in the database table and filling up the data disk.

Upvotes: 0

Josh Hansen
Josh Hansen

Reputation: 11

I have seen other web properties introduce a new password reset system (much better than CAPTCHA) which provides some form of 2FA (two-factor authentication) where you can telesign into your account, in place as a back-up. User gets a one-time pin code sent to their cell, and enters that in. No spam filters to deal with, captcha forms to reload, etc... much easier. Prevents bulk registrations, spam, and generally seems to be more effective and user-friendly than alternative solutions.

Upvotes: 1

JB Nizet
JB Nizet

Reputation: 691943

Why not simply add a CAPTCHA to the password reset request form? You could then limit the number of requests per email address and per day/week/month, but a CAPTCHA would keep bots away.

Upvotes: 5

Vineet Reynolds
Vineet Reynolds

Reputation: 76719

Assuming that you are writing an application meant to be used on the internet, where you cannot control registration of users, you can set a rolling limit on the number of password reset attempts that are attempted on a user account.

The rolling limit would be used to ensure that too many password reset requests are not sent out within a short duration. You can limit users to issuing 3 password reset requests, but only within 1 hour, or may be even 1 day; your business should be capable of determining the optimum value, especially if users can also issue password reset requests via other means (by sending emails or calling up a service desk).

Also, you can associate the generated tokens (I'm assuming that you are sending out password reset tokens with each mail) with a predefined expiry date, and all such tokens may be used only once. Tokens should ideally not last more than a few hours. Highly sensitive applications would also audit all password-reset requests in addition to the usual authentication attempts.

Finally, you can also establish limits on the number of password reset requests originating from a certain IP (this is a DoS prevention attack and wouldn't work against DDoS attacks). Needless to say, but the associated accounts should not be disabled in the interim, if an attempt was made to reset the password. Doing so, would enable a successful DoS attack where in an attacker can disable accounts by simply issuing password reset requests against a known email ID database. You will have to account for ISP proxies in establishing the limit, or you might actually hurt a few customers in the process.

Upvotes: 2

Troy Hunt
Troy Hunt

Reputation: 20397

Be careful about settings limits by IP. You've often got a single internet gateway exposing large number of users through a single IP (i.e. corporate networks).

If you're worried about the number of requests made to reset a particular address, this is more of a usability issue than a security issue. I'd be inclined to define an acceptable rate which balances not allowing too many reset requests with not making it too difficult to perform a reset (i.e. original email gets caught in junk so another is requested). For example, log the time of the request and not allow another one for another 15 minutes.

Pragmatically though, I wouldn't be too worried about this. There are endless ways to screw with someone via email if you really want to so unless there is something particularly attractive about exploiting your reset feature, I'd just be doing what most sites do and allowing resets when required and only actually resetting the password after the user receives the email and actions it.

Upvotes: 0

Related Questions