[TO CLARIFY] Account Re-Verification on Email Change

[videsignz]

I was thinking...
If we use email verification for an account on creation, why would we not do the same when a user changes their email?

To me this only makes sense. It could go something like this...

1. User changes email and is logged out
2. User DB status changes back to inactive
3. Email resent to verify
4. Link clicked to reactivate

Obviously there should be some sort of notification shown to the user alerting them that their account will be set back to inactive.

Thoughts?

Here is a quick setup for the function (Not tested)

    public static function saveNewEmailAddress($user_id, $new_user_email)
    {
        $database = DatabaseFactory::getFactory()->getConnection();
        $user_activation_hash = sha1(uniqid(mt_rand(), true));

        $query = $database->prepare("UPDATE users SET user_email = :user_email, user_active = :user_active, user_activation_hash = :user_activation_hash WHERE user_id = :user_id LIMIT 1");
        $query->execute(array(':user_email' => $new_user_email, ':user_active' => 0, ':user_activation_hash' => $user_activation_hash, ':user_id' => $user_id));
        $count =  $query->rowCount();
        if ($count == 1) {
            if(RegistrationModel::sendVerificationEmail($user_id, $new_user_email, $user_activation_hash, true)){
                LoginModel::logout();
                Redirect::home();
            }
        }
        return false;
    }

[panique]

Hmm interesting! This means the account would be inactive until the user confirms the new email.
Good idea, but i see some problems, like when you accidentially mistyped the new email then there will be no way to ever get back into your own account.

Question to everybody: How do big sites handle this ?

[slaveek]

Two email inputs.

• type new email
• retype new email

This can be easiest.

[OmarElgabry]

Good point! I see the following solution could be appropriate:

Approach 1

1. Make a new column that stores the user old email temporary(if exists).
2. Whenever user asks to change his email, generate new tokens for emails and set user_active to false.
3. Send a notification to user old email, and new one.
4. The notification to old email should contain a revoke action, so that user can revoke his old email(stored in the new column).
5. The notification for new email is asking user for confirmation.
6. Once user confirmed, set user_active to true again, and clear tokens.

Approach 2

1. Make a new column that store the user new email temporary(if exists).
2. Whenever user asks to change his email, generate new tokens for emails. Now, user can still login with his old email until he confirms the change
3. Send a notification to user old email, and new one.
4. The notification to old email should contain a revoke action, so that user can revoke his old email(stored value in new column will be removed).
5. The notification for new email is asking user for confirmation.
6. Once user confirmed, replace the stored user new email with the old one.

Approach 3

1. Make a new table called user_emails with 1:M relationship with users, where each user can have multiple emails, each with user_active, and a token.
2. Whenever user asks to change his email, generate new tokens for emails. Now, user can still login with any of his current emails.
3. Send a notification to user current emails, and new one.
4. The notification to current emails should contain a revoke action, so that the new added email will be removed(assuming there are more than one email stored for the current user).
5. The notification for new email is asking user for confirmation.
6. Once user confirmed, set user_active to true for the new email.
   Instead of sending notifications for all user current emails, you can ask the user to choose a primary email. This email will be the used for such transactions.

Some general notes:

• As for updating the email, as @slaveek said you can ask the user to enter the new email, and confirmation, this will reduce mistakes by user.
• If your application updated the database and set the user's new email, but failed to send both emails, you need to revert back to old state, and output an error message.
• Always ask the user to re-enter his credentials(email and password) again.

NOTE I'll keep this comment updated whenever something better, or if i found a security hole in the above steps.

Updated 26/08/2015 9:57 GMT

[slaveek]

@OmarElgabry

Your application will then send an email for the new email asking the user to verify it, and another notification email to the old email asking the user to report or revoke the changes if needed.

I think that two emails shouldn't be send the same time. If someone use verification link in new email first then will be to late to revoke changes.
I can see that in a bit different way:

• send request changes link to old email (with warning and possibility to cancel)
• open change email form asking user for password
• when user click on change email button, deactivate account and send verification link to new email address
• click on verification link in new email

[OmarElgabry]

@slaveek

If someone use verification link in new email first then will be to late to revoke changes.

Updated 26/08/2015 9:57 GMT
You can revoke it only in the first approach, and assuming this "someone" won't change again the email!. But, If a hacker, or even a normal user puts his hands on user's account, then it's the users responsibility, because he is the one who confirmed updating his email, and he entered it twice.

It don't see a big difference, in both ways you are going to send email to new and old user's email one after another.Let me know if i missed something here.

[panique]

Btw if the user really mis-spelled the email adress then it's still possible to login with username.

[videsignz]

@panique that is spot on, It would simplify implementing this as well.

[panique]

As this is a good, but also a very advanced feature and would bloat the project quite much I would kindly close this ticket, but link to it from the readme, so people who really need this feature will still find this ticket.