What is the suggested best practice for changing a user's email address?

Question

I recently jumped onto the hypetrain for an unnamed email service and am currently on my way to update all my accounts on various websites to get most of my (future) data off Google's Gmail.

During this adventure I came across a couple user-flows of changing your e-mail address which I would like to share (amounts like "many" or "a few" are purely subjective, I did not count):

1. No questions asked

   The email address is just changed without any confirmation emails, second password check, or spellchecking (two input fields). The email address is the main login method to this account with some sensitive data. Any person with malicious intent will not be stopped from taking over my account if they change the email address and afterward change my password.

2. Confirmation of new email

   What I feel like the method used by most platforms: You will receive a confirmation email to the new address you provide. This will assure you typed in the email correctly, but will not stop anyone from changing the main login method though.

3. Confirmation through old address

   Very few platforms send an email to the old address to check if I am the actual owner of this account. If I click the link in the mail or enter a number they send me, the address is changed.

4. Confirmation through old and of new address

   Just once I had to confirm with my old address that I am the owner of the account and got another email to the new address to check that it does indeed exist.

Looking back at it, it feels like the usual UX vs security conflict. While method 1 provides the most comfortable flow, I see the most issues with it, as already pointed out. Having to confirm the old address and the new one is kind of a hassle, but it's the best way of those listed to keep the account of your users in their own hands.

Are there other common methods I am not aware of? What is generally considered best practice?

Answer 1

The problem I see with confirming the old email address is that sometimes people change address because they cannot access the old one anymore. For example, the old address might have expired (and maybe even reassigned to someone else!). Or they might just have forgotten the password to the old address, and have no alternative ways to prove their identity. Or the old address belonged to a company where they used to work, and they don't have access to it anymore. Or it might have been blocked or terminated for for other reasons (violation of ToS, DoSed, filled with spam and practically unusable, etc.)

So the way I see it, you have two ways to log in to an account: using your password, or using your email account to request a password reset. Therefore the email account is an alternative way to authenticate. Now, whenever you make changes to the ways you can authenticate, you should verify your identity. And if you can't rely on the old email account (that you are about to change) the obvious solution seems to ask for your current password before you can change the address.

• Ask for your current password (it's a valid verification of your identity) to be able to change the email address.
• Verify you have access to the new email address and, if verified, make it the new default one.
• Maybe do something with the old address that has been changed.

What you do with the old account, in my opinion, has some pros and cons. You could decide to:

• Send a notice to the old email, for example: "Your email address for accessing Website Example has been changed, if you didn't expect this your account might have been compromised, etc." You might also provide a link to recover the possibly compromised account, with a token that expires after some time. The problem with this option is that if the old account has been reassigned to someone else, you would not want to let them know too much information (and definitely not give them a direct recovery option)
• Just throw away the old email once it's been successfully updated, without sending any notices. The problem with this is that if an attacker manages to steal a user's password, they can take over their account completely and lock them out.
• Don't send anything to the old email, but keep it in the database for some time, for support or recovery, in case the real owner of a compromised account (with the old email) shows up asking for help. The problem with this option is that the real owner, in case the account is compromised, might not realize it until... how long?

Answer 2

2. Confirmation of new email

What I feel like the method used by most platforms: You will receive a confirmation email to the new address you provide. This will assure you typed in the e-mail correctly, will not stop anyone from changing the main login method though.

This should be the 'correct' way. Rationale:

• this confirms that the mail address you entered was correct and free of typos
• that you have access to it
• and that the mailserver hosting it is reachable and will accept the mail - there could be a DNS misconfiguration, or a spam filter preventing mail delivery

So the change of mail address should not be carried out until it is confirmed.

There is one problem with this method: if you were logged in on a computer that is left unattended, someone else could change the mail address and take over your user account.

The solution is to confirm the request with the current password. That's one more step but I feel that the inconvenience is tolerable: users should not change their registered mail address often.

Variant: you can ask for an answer to a secret question if your site has that option at signup. Preferably not a secret question like birth date which is probably public knowledge...

Rationale: it is possible that your password was compromised and found in some pwnlist, especially if you reuse the same password across sites. But there is a chance that the answer to your secret questions will not be found easily. The downside: the questions and answers previously recorded should then not be visible or modifiable anymore. That means you should be using questions that have stable/permanent answers while avoiding the trap of common, not-so-secret questions like the birth date or mother's maiden name.

So maybe this is an option that is practical for some sites but not all of them.

3. Confirmation through old address

Very few platforms send an email to the old address to check if I am the actual owner of this account. If I click the link in the mail or enter a number they send me, the adress is changed.

As hinted earlier, the user may have lost control of the old address, it may be a professional address from a business you left (or were fired from). Or the address could have lapsed or been allocated to someone else. There is a risk of unwanted information disclosure here. Once you've confirmed the new address the previous one should not be used anymore.

Last but not least: log all changes made to the user profile. If someone reports unauthorized access you should be able to tell when the change was made and the IP address that initiated the change. Actually, the confirmation mail will often include the IP address. Clarify this in your privacy policy: what kind of information you record, when and for how long while ensuring compliance with applicable regulations.

If your site has 2FA and the user has it enabled, 2FA confirmation would be desirable, depending on the nature of the service. If you just want to change the mail address for some free newsletter subscription - 2FA is not justified. If you're a bank, it's different. SMS/OTP will probably come into play.

Answer 3

If you consider email as a form of verification of account identify then ideally you should be looking to confirm any changes via an alternative form, for example sms, other email account, soft token, physical letter etc.

In many cases email is the primary id for your account and depending on how secure the account is you will need increasing forms of alternative validation.

• Example 1 in your question is totally insecure and flawed on many levels
• Example 2 is still insecure as the malicious actor only needs to confirm the change on the email service they control (no original email factor validation)
• Example 3 should be the minimum, however additional validation/verification factors should be employed if the account is aiming to be secure
• Example 4 is not really any more secure than 3 and only really aids in making sure the new email is valid

Best practice should be to validate on alternative communication factors. How many and what type depend on the service and the risk appetite of the vendor.

Answer 4

Confirmation of the new e-mail is definitely worth including in the best practices. The alternatives (like typing the new e-mail twice) are just as time consuming and not as certain.

Confirmation of the old e-mail is self-defeating (many users only think about changing the address when it already stops working). However, sending a recovery link to the old e-mail on an e-mail change may help to prevent accounts with weak passwords from being easily stolen.

There is a slim chance that the old address was not just disabled, but reassigned to a new user. However, if the old account has been reassigned to someone else, and that someone has malicious intents, the original user is screwed regardless of the recovery option on e-mail change. They could have just as well have the account's password reset, preventing the legitimate user from updating the e-mail in the first place.

Answer 5

It depends, as always, on the threat model. What can an attacker achieve if they change the email address on the service?

For example, a service that sends notifications of events I have to react to to avoid a negative outcome (e.g. a notification that someone is sending money from my account, and if I didn't initiate the action I should contact their security contact) is at a rather high risk of being attacked through this avenue. If you manage to get hold of a password and are subsequently able to change the notification address without a notification being sent to the old address, the notification service might as well not exist because it is easily disabled in precisely the scenario it is designed for.

On the other hand, information disclosure like "this user is switching their LinkedIn account away from their company e-mail address" is another realistic threat scenario in which the exact opposite is desirable: there should be a way to change the email address without a notification being sent to the old address (especially if the notification follows a standard format that can be easily scanned for). In this case, it might be better to display a notification that the email address was changed during the login, and repeat this notification for a fixed time (so an attacker cannot acknowledge it to hide it from the real user).

Also, quite often a lot of details about a user change simultaneously, for example a company email address and company phone are deactivated on the same day, and the person subsequently moves for a different job so the address also changes. For consumer services, divorces are pretty much the worst case -- quite often, one person is on the other's phone plan, so the phone number attached to an account belongs to a different person than the billing information, or a person might change an account's billing information to their own in order to take ownership of an account that paid-for items are attached to, so actual account ownership is difficult to tie to a specific item.

There is no single "best" way to handle this. Look at the specific application, and play out a set of possible scenarios where an attacker would have a motive to alter information about an account, and what the account owner would want to happen in this case.

Answer 6

You probably don't want to confirm with the old email address, as one reason to migrate is because an old email account has been compromised and is no longer in the control of the legitimate account owner. You might want to inform the old email address that the account has been changed, and provide them with a point of contact where they can contest this change if needed. This point of contact would need to put additional scrutiny on both the new and old email address so that it doesn't become the weak spot in the security model where a social engineering attacks can occur.

You might look at other vectors for verification or informing users, 2FA, SMS, etc. You sort of identified the root of the problem, there is a trade off between security friction and easy of use. There is no magic bullet, because every use case is going to have differing costs associated with it. IT probably isn't really a big deal if you lose control of a casual message board account, but that will not be the case if you are building account management controls for international banking software.

Pick your poisons accordingly.

Answer 7

I recently had to change email addreses on a numb er of sites, because my ISP stopped doing email (their reason bopiled down to "it's tooooooo hard, mommy"). An email address I have had since 1993 stopped working in August last year.

I came across a couple of sites whose policy was simply "you can't change your email address." I had to create brand new accounts on those sites, using a new email address. One of them had a process to migrate purchased content, the other didn't.

This has the advantage of being simple for everyone concerned. Create a new account, exactly as if you was a new member of the site.

Answer 8

Solution 1 is trivially broken by mundane user error. Solution 2 is the optimal in my opinion. Solution 3 and 4 have better security but leave your service open for a serious availability issue.

I used an academic email address to register to a few services (I know, my bad). When the address expired, I became unable to change the address of one of them even though I could login because I knew the password. The feature to change the address required old address confirmation. So it became a ticking bomb.

Another service was even worse. I forgot the password so I was completely locked out. To be fair I'm not sure of how you could design a system that can automatically deal with the user losing all credentials.