The ONLY correct way to handle users changing their email address

Hey, you try finding a photo of email changing!

Like many people who have been on the internet for more than 5 years, I have been burdened with an outdated email address for some time now. This is a common problem, whether it be something as embarrassing as an email ending “@aol.com”, or one of the equally common teenage-years “x_x_happychick101_x_x@hotmail.com” or… you get the idea.

So recently I decided it was finally time to move to a more modern email provider, which was a fairly simple thing. However what proved not to be a simple thing was the act of changing my email on all of my many, many accounts (200+ by my last count).

This led me on a journey that at best, took only a few minutes per website, and at worst, led to me submitting GDPR requests to delete my account data. My intention of course was a simple one: “change my email address”. But below are the realities I encountered on this journey.

Wrong way #1: No ability to change email whatsoever

This one really made me laugh, and happened a lot. Even some of the biggest companies in the world simply do not provide an ability to change your email address with them. Their only option is that you register a new account with your new email, and then… use that one.

The first issue with this is that you then lose access to all of your past data. Ordering groceries and want to see what you ordered last week? Log into last week’s account then. Spent weeks setting up your profile so your flight bookings are super simple? Tough luck, do it all again on your new account.

The second issue is that you end up with an orphaned old account, potentially filled with data that has no reason to exist. This led to numerous requests on my part for my old data and accounts to be deleted, which is a slow and painful process (though it has thankfully been made a little easier thanks to laws like GDPR).

The weirdest thing about this is that it damages the data the company hold too. Instead of having data on a user’s complete journey with them, they have multiple split records containing different pieces of data, and an additional obligation to delete some of those older accounts as they become inactive.

The only reason for this approach is because your company is lazy. Stop it.

Wrong way #2: Requiring staff to facilitate email changes

Sometimes I would go to change my email only to be told that I must submit a request, go on live chat, or in the worst case; pick up a phone and call in.

You might think this was more common with more sensitive accounts such as online banking, but in reality it was some of the more tedious accounts that had such restrictions (all of my bank accounts actually allowed me to change my email address without issue).

This approach does allow companies to impose a little more security, but it also makes your users unhappy, and takes up the time both of them and of your own staff.

Once again, this approach typically points to lazy system design. Stop it.

Wrong way #3: No validation

This was by far the most common scenario I encountered. You log into your account, click “edit” next to your email, put in the new one, and click “save”. Done.

This was heavenly and made my job 10x easier, but it isn’t in the least bit secure. For one thing, if someone were to access your account maliciously, and try to change your email address to one they have control over, this method does absolutely nothing to stop them.

Another issue is that it doesn’t verify you have access to the new email either. Oftentimes it wouldn’t even ask for you to type confirmation of the email (which is fine — who manually types emails in these days anyway!?). So I expect numerous cases of users putting the wrong new email address in and then losing access to the account.

Wrong way #4: One-way validation

A less common approach (but still a regular one) was for the website to verify you have access to the new email address by sending you a code or verification link. In even less common cases, they instead asked me to perform the same action on my old email, but not on my new one.

This is obviously an improvement on the above methods, but it still isn’t enough. If I’m a malicious attacker, proving I have access to the new email offers no security whatsoever. Likewise if I prove I have access to my old email, and then spell my new email wrong, I’m still screwed.

The (only) correct way: Double validation

As you may have guessed from the above methods, the correct way to offer email changing is to do so only once a user verifies they have access both to their old and new email accounts. This means attackers who have a user’s password but no access to their email address can’t steal their account, and stops users from innocently entering an incorrect new email, losing access to their account in doing so.

Of course, implementing this method does mean that if users lose access to their old email address, they won’t be able to change it themselves, and will instead need to contact you to verify their identity. But I personally would argue that this is far less cumbersome than the mess that will come from a user having their account (which is potentially filled with sensitive information) stolen from them because you didn’t implement basic verification measures.

One additional minor issue with this approach comes when websites use verification links rather than codes. Don’t get me wrong, I like verification links; they’re simple and pretty elegant. However the flow then becomes that you click “verify old email”, then you check your old emails and click a button, which opens a new tab, then you click “verify new email”, and repeat the process. By the time you’re done you have at least 3 tabs open, and if you only have access to your emails on a mobile device this means multiple sessions too. Codes you can type in on the initial account management tab are great at avoiding this issue.

In closing

So there you have it. This article represents weeks of pent-up frustration with poor UX, and even worse data protection and privacy policies. But hey, if even a single person reads this article and thinks “Oh, I should really implement double-verification”, I’ll feel like it was all for a good cause.

Full-stack software developer from the UK, author of the Aftermath book series, full time tech-nerd.