Is it helpful to slow down the password reset function?

Question

I've implemented a password reset function for a website I'm working on. By default, the function is very fast, and I'm wondering if it would be helpful, from a security standpoint, to intentionally slow it down a little.

I'm thinking of simply adding a sleep call at the start of the controller action.

My reasoning is, a user who is genuinely trying to reset their password, probably won't be bothered by waiting an extra 5 seconds or so, to receive the confirmation that the password reset email has been sent. However this extra 5 seconds, I'm hoping could help slow down a bot.

One of my main reasons for wanting to do this, is because previously the reset function didn't give any indication if an invalid username was entered. This was to prevent malicious users from attempting to find valid usernames. I've been asked to change this though as users were finding it confusing.

As the reset function can now be used to determine if a username is valid, I wanted an extra level of security to help prevent malicious use.

Answer 1

There's no need to make it possible to enumerate usernames via the password reset function. Simply offer a box for an email address (or username, if email addresses aren't guaranteed to be unique in your system), and any time somebody enters one, give them a message saying "if we have (that address|an address corresponding to that user) in our system, we have sent an email. Please check your email, and note that it may take a few minutes for the message to arrive. The email will be valid for [some short time]."

If you want to slow down attempts to abuse the password reset system anyhow, a good CAPTCHA is probably a better bet than an artificial delay.

Also, I echo everything in @neonprimetimesecurity's second paragraph, with the addition that not only should the link be cryptographically random and unguessably long, it should no longer work after one use regardless of the time remaining until it expires. (You can make "one use" mean "once the password is actually reset" if you want, sometimes people run into issues with email scanning services that request every URL in an email and end up invalidating links before the user gets them.)

Answer 2

There is always benefit from a security perspective if you can slow down an attackers/bots (captcha , sleep statements , etc) without impacting normal business use cases , but I think that's more of a call on your part , weigh the ROI and determine if it's worth it.

I think if you're threat modeling a bigger initial concern than enumerating usernames would be to ensure your password reset process itself is secure so that nobody can take over an account with it. Is the email validated? Are you sending a password reset link instead of a password ? Is that link temporary and expires ? Is that link random and not guessable ?

Answer 3

You are right that an "unguarded" password reset function could be used maliciously, e.g. for user enumeration or spamming your users with emails.

However, a call to the sleep function could make you vulnerable to DOS attacks! Your server probably has some explicit or implicit limit on the number of concurrent HTTP requests it can handle. If you got an endpoint that will take at least five seconds to complete, that's bingo for an attacker!

Calling sleep doesn't really limit how many requests the attacker can make - she doesn't even need to wait around for the response. It just makes you waste more system resources.

What you want to implement is some kind of rate limiting, e.g. based on IP address, or a CAPTCHA.

Answer 4

As Anders says, pausing your code means that it is occupying resources on your server for longer - so you are creating a possible avenue for denial of service. You could implement the delay at the client - but this is something the user can control and therefore ineffective in its objective.

Not limiting the rate control provides an avenue for DOS against the target mailbox.

A potential solution is to disallow reset rests for a window after a reset code has been issued.

You do not control the speed at which the email appears in the user's mailbox. So not restricting the rate at which resets are requested could undermine the legitimate use of the facility - user requests password reset. Email with reset code 'A' is sent to mailbox. User gets bored waiting and issues subsequent reset. Email with reset code 'B' is sent to mailbox. Email 'A' arrives at mailbox and is activated by the user. This is rejected by the site which is now waiting for reset code 'B'. Conversely, an attacker can keep hitting a site with invalid reset codes thereby preventing the legitimate user from resetting their password.

Such a simple thing quickly gets very complicated.

This is the fun of programming!

Answer 5

You could delay the function, but as an outside process, not inside it.

I explain:

User forgot the password, so he asked for a reset. Send him a link that will work only after 5 or 10 minutes. If the link is used before that, ask the user to wait until those minutes have passed.

Send a message to the primary and backup emails for the user stating someone from certain IP, browser and OS is trying to reset his password, with a link to cancel the request if isn't him.

After the wait, the user can access the page to change the password. You could lock the user out for a couple more minutes, sending a mail to the user telling him his password was changed and with a link to revert the change if he wants to. So save both the old and the new passwords on the database before the change occurs.

Using this, you will not DoS yourself, or lock out the user, and create a delay giving the user a slight chance to revert a change he haven't started. And make a couple users furious, of course...