Security riddle: confirming email and resetting passwords

Question

I'm using Devise on my Rails 3.0 app, and we currently have confirmable and recoverable turned on. These modules require users to confirm their email account (confirmable) and allow users to reset their password by having an email sent to their email account (recoverable).

Unfortunately we've had difficulty "devising" (pun intended) a reasonable security policy that permits users to use the site without confirming their account. We enforce the following requirements for security:

1. Confirming your account requires being signed in or signing in. Were this not the case and user A accidentally entered the wrong email address of malicious user B, B would receive the confirm email link, get automatically signed in, and from there could reset the password via "email reset password link." Requiring B to sign in with A's credentials eliminates this possibility.

2. Resetting your password via email requires having a confirmed email. This is because if user A accidentally enters the wrong email address, one belonging to malicious user B, then B will receive the confirm email link and know that A has signed up for an account. So B can visit the site and use the reset password functionality to change the password on the account, and subsequently can confirm his account. Requiring a confirmed email address eliminates this possibility.

So all is well. Except when user A creates an account, doesn't confirm his account yet, and then returns to the site and forgets his password. Here A is caught in a circular dependency loop, where resetting his password requires confirming his account, but confirming his account requires signing in with a password that he has forgotten.

Two possible solutions:

1. Requiring users to confirm their account immediately after signing in. This creates more sign-up friction, but eliminates the circular dependency.

2. Permitting users to reset their password without a confirmed account, but not allowing users to enter any sensitive information or perform critical actions before confirming their account. This way an account hijack by malicious user B is still possible, but he will gain control of an account without any valuable information or power.

Are there better solutions out there? How do companies deal with this issue? I've used several sites that do not require immediate email confirmation, so it'd be nice if we could do this in a way that doesn't require implementing something as complicated as #2.

Thank you!

Answer 1

Create a sort of role where a user is authenticated, but not confirmed. It is not unreasonable to require a user to confirm their account before making any account changes (such as resetting their password or email address).

I think the trick here is really just that you can let a user confirm account without being logged in. If User A put in the wrong email address, then what can you expect to do? Do your best to help them put in the right email address at the beginning. This is a rather unforgivable sin for the user - they should know how to put in their email address. If they can't get the email, and used the wrong account, the last resort is for you to do some tech support and/or give them some security questions to help them recover their account.

After clicking the "confirm" link in their email, they should be asked to log in. Simple as that. "Thanks for confirming your account, please log in". Don't automatically log them in, as this could be a security issue, especially if they have a "profile" with sensitive information.

In your scenario where a non-confirmed user forgets their password. Tell them they have to confirm their account first, offer to resend the email. After that, give them the option to reset their password via email. It is clunky, but the user will probably be understanding if you explain why they have to go through this. They are the ones forgetting all their information, so they shouldn't be too harsh on you.