Implications of a 6 digit password reset token

Question

I'm designing a password reset system for my website/app right now and I'm not sure if the solution that I've reached could be considered suitably secure. The steps for resetting a password are as follows:

1. User visits the login page (HTTPS) and chooses 'Forgot Password'.
2. The user submits their email address (or username as the app allows sign-in with either).
3. If no account is found with the provided email/username then no email is sent (user is not warned of this to prevent user enumeration).
4. A 6 digit number is randomly generated as the reset token and stored in a key-value store (with the key being the token and the value being the user's ID). This store entry is configured to expire after 1 hour.
5. The token is sent to the account's email address.
6. The user then submits the token onto the same page that they provided their email on (the page contents changes to provide an input for the token).
7. If the token is valid then the corresponding store entry is prematurely expired and the user is prompted to provide the new password (with a 'repeat password' input to double-check).
8. On submission of their new password, the user's database record is updated to reflect this change and all active login sessions are invalidated.

This system doesn't use the standard method which involves generating a longer token (which comprises of a larger character set than just numerical digits); is this considered insecure?

My reasoning for this method is that our app is being developed for young people (specifically children and teens) and so this password reset system should be as simple as possible. This system means that the user doesn't have to change the page they're on (as the form to provide the reset token is automatically displayed after the email is sent) and they don't have to open any link from the email meaning that only one browser tab is ever used (and it's the same tab).

And from what I can tell, another benefit to this system is that password reset token is never exposed to any logs as it's never included in any URLs, although it's still exposed in the email however that's not something I can get around.

Can this system be considered suitably secure?

Also, would implementing a CAPTCHA service anywhere make this system more secure, or should I only ever consider adding one if we start to see too many requests being made?

Answer 1

The password reset scheme you describe looks OK, but you are leaving several questions unanswered at point 7, which are relevant for evaluation:

• What happens, if the token the user submitted is wrong?
• How many tries do you give the user before considering the reset attempt failed and block further token submissions?
• If a reset attempt failed, can a user retry resetting his password again?
• Is there any rate limiting (e.g. only one password reset attempt per account per day)?
• Do you monitor failed attempts and react to such attacks (e.g. block an offenders IP address)?

The answers to these questions allow you to calculate the probability of an successful brute-force attack.

6 digits means a number in the range from 000000 to 999999. This gives you one million different possible tokens. Let's assume you allow up to 10 token submissions per reset attempt before you consider it failed and block further attempts. This gives an attacker a slightly better chance of success than 0.001% for a reset attempt.

That seems like a low probability, but if the attacker can automate the process and there are no limits how often a password reset can be triggered, a successful attack becomes likely fast. If an attacker makes 10000 such attempts, he has a probability of success to reset at least one account of around 10%. Ramp this up to 100000 attempts and you we are talking of a success rate of around 64% to reset at least one account. This does not look secure at all anymore.

So the real question is, can you prevent an attacker from making such a huge amount of reset requests, considering that it doesn't matter if they are done for a single account or multiple accounts.

You also talked about simplicity of the process. If you do not want to use a complex character set for the token, that's totally fine. Length is much more important anyway. If you want to make the token stronger, I would recommend adding a few extra digits. But in the ends, it comes down to protect against brute-force attempts.