I am writing a web app and I want to set up a system where, when a user changes their email, it gives them a link to have the change revert back. The purpose of this is for when a hacker changes an account email. In this case the user can't log in without it being reverted. Login is email + password.

I need to handle a hacker doing multiple changes trying to use up a revert list. And I don't want the ability to revert by just entering an email as that would allow major mischief by hackers. So I came up with the following. Will this work? Is there a better approach?

  1. On an email change, I create a GUID and then save in the DB the GUID, old email, and old password hash.
  2. The email sent to them lists the change and says to revert click the link. The link has the GUID in it.
  3. Upon receiving that link, it reverts back to the previous email & password hash.
  4. If possible (I'm using Blazor server), it will log out any other sessions for this user.
  5. Should I then force them to use 2FA?
  6. Nightly clean-up will delete any revert records that are over a month old.

Will this work? Any security holes?

Based on the below replies (thank you) then what about the following? (Asking here because I don't think it's worth a distinct new question.)

When it is changed, send an email to the old & new email with a GUID & link. Clicking that link, which has the GUID as a parameter, asks if they want the account disabled and provides the support phone & email for them to call.

That way we stop any further damage and then turn it over to human beings to figure out what to do.

I am not selecting an answer from the below as the accepted answer because I think several of the answers make very good points and I don't know this topic well enough to select which is best.

  • 2
    I would limit the rate of email changes as well. In addition, depending on your sector/country, the regulatory requirements may dictate the number of emails you can hold on file, which takes the choice out of your hands.
    – billc.cn
    Commented May 31, 2023 at 10:37
  • 2
    Your new approach sounds reasonable. However, I'd set a short time limit of, say, a week where it's possible to block the account from the old address. After this, the address change should just be accepted as legitimate. Also, establishing a third authentication method besides the e-mail address and the password really should be the priority (a mobile phone number, a recovery e-mail address, security questions or anything like that).
    – Ja1024
    Commented May 31, 2023 at 17:59
  • One more thing: even if the hacker doesn't change the E-mail address on file or anything else - he's still logged in and has access to the account. He can remain stealth. I suppose that is already bad enough but you're not addressing this scenario. That makes the case for early detection. Example: some sites have an option to notify by E-mail of failed logins attempts (even successful logins too) but it's often opt-in because users may find notifications annoying.
    – Kate
    Commented May 31, 2023 at 21:57
  • @Kate I didn't mention it in this post. And it's moot because based on the feedback here, I'm not going to do it. But I would also, if this happened, immediately kill every existing login for that user. Commented Jun 1, 2023 at 0:03
  • 2
    Remember that virus scanners and other security filters could very well follow the link automatically to check for malware.
    – jcaron
    Commented Jun 2, 2023 at 11:43

4 Answers 4


Your scheme completely defeats the purpose of changing the e-mail address. When a user wants to change their address, there's a good chance they're doing it because they no longer control the old address. If you then let anybody who does have access to the old address revert the change (against the will of the legitimate user) and take over the user account, you're actually creating a vulnerability.

This could also lead to an interesting ping-pong of address changes, where the attacker and the legitimate user take turns in reverting the other party's address.

You won't get around the fact that a user has to authenticate with something. If they've forgotten their password, they should be able to authenticate using their e-mail account and change the password (the classical I-forgot-my-password e-mail). If they no longer control their e-mail account, they should be able to authenticate with their password and then change the e-mail address. If they've lost both, it's over -- unless you introduce a third authentication option, e. g. security questions which are checked over the phone.

  • 3
    Often when you drop an email address it isn't immediately given to someone else. It's a good idea for email providers to quarantine the account for a period of time specifically to give the original owner's correspondents time to update contact information so they don't send to the wrong recipient.
    – Barmar
    Commented Jun 1, 2023 at 14:25
  • 4
    I was thinking more of abandoned e-mail accounts that get compromised, not address reuse by the e-mail provider. I agree that providers shouldn't simply hand over an address to somebody else.
    – Ja1024
    Commented Jun 1, 2023 at 14:37
  • The ping-pong situation is what I was thinking. I'd assume in this scheme you would not send the revert email in the case that the email was changed via a revert link, however, If the attacker knows the scheme, they just need to change the email address two times so they get the revert link once and can use it if the actual users ever reverts the email address. Of course you could add checks that a link can only be used once and/or using a link invalidates all others, but still could be some breakpoints on that front. Commented Jun 2, 2023 at 19:32
  • @HenryWoody Make the oldest revert take priority, once it's been used any newer revert becomes invalid. Commented Jun 2, 2023 at 22:51

Maybe you work for a big company like Facebook where the number of users is so huge that you have to automate the process of recovery. But I assume you are not working for such a company and that the number of incidents in any given year is small or downright nil. So if you're trying to anticipate a hypothetical situation that may never occur, it doesn't look like a smart allocation of resources.

As said already, this could turn into a ping-pong party where the attacker and the legitimate user fight over the compromised account, and you are not solving anything, merely adding confusion and frustration in the process.

But there are quite a few things you can do to improve things. Here are some ideas. If a change of E-mail address is performed (or changes are made to any other sensitive fields in the user profile),

  • log the details, because auditing is important and can be crucial during investigations.
  • send a notification to the previous E-mail address to notify the user (even though they may no longer own it).

Reacting quickly to unauthorized changes is key, because the relevant logs are often short-lived.

Roll out MFA now. That's what you should be doing before devising esoteric approaches. Use the tools already available on the market to tackle the problem at the root. Then the risk of account takeover will decrease. Of course you'll have other issues. Some people will inevitably lose their tokens and you'll have to vet them manually. Is this a big deal?

What you could do perhaps is to require users to provide an alternative communication channel like a secondary E-mail address, a phone number. Because it's less likely that a hacker will be able to control all of those.

You could also add a secret question at signup (don't show the answers in the control panel then). The idea here is to have something more permanent, possibly frozen. But it's not without problems, because people make up stuff or forget answers, or give out guessable answers, so I would prefer to rely on a mix of possibilities.

But if there is a secret question in place, you could use it as a challenge before a change of E-mail address is allowed. Or present a 2FA challenge. This creates one more obstacle for the hacker.

While you are it, you can send notifications by E-mail when multiple authentication failures are made, and cap them. This gives the user an opportunity to react quickly to an ongoing breach.

In short: there is a lot you can do to thwart attempts at account takeover. Invest more time in prevention, rather than trying to fix things in a less than perfect way.

  • "Some people will inevitably lose their tokens and you'll have to vet them manually" Can you give an example of how you would vet them manually?
    – eaglei22
    Commented Apr 1 at 1:50
  • 1
    @eaglei22: vetting people manually means they would have to get in touch with you by E-mail or phone and prove their identity by whatever appropriate means. For instance, some sites may ask for a scan of ID. Or they will ask questions related to your website usage, that only you would normally know. If it's someone you know personally like an employee, then a simple phone call can settle the issue. Not taking into account any possible advanced deepfake scenarios though.
    – Kate
    Commented Apr 1 at 22:54
  • Okay thank you. I'm designing my own web application and working on some sort of account recovery in the event user loses access to email. I started thinking about recovery codes, but with the audience I'm expecting, I don't think they will take it seriously. So I was considering some sort of manual recovery option as a fail safe. It was suggested to me with the possibility of ID images being faked, that sometimes it's better to just allow the account to be lost/locked and have the user create a new account. So I was curious what your methods were.. I like questions on website usage though.
    – eaglei22
    Commented Apr 2 at 4:16
  • You may add more recovery options when setting up the account. For instance, a mobile phone number on file could be used to receive a reset code, although SMS is not considered safe nowadays. Also, a secondary E-mail address could be entered to receive password reset links in case the main address is unavailable for some reason. And then there is the so-called security questions with answers only you should know. A recovery procedure could include a mix of two methods for example.
    – Kate
    Commented Apr 2 at 12:31
  • The point is, it depends on what kind of service your website provides. If you provide E-mail service, then it is crucial for users to be able to regain access if they use the E-mail service for anything meaningful. For a webshop, the user might as well create a new account, because the old account only contains order history, maybe products reviews and some payment options. So the loss of access is not catastrophic here.
    – Kate
    Commented Apr 2 at 12:34

(Not a direct answer to OP's question, which I believe deserves its own proper answer without being turned into an X-Y thing, but this is too long for a comment:

Using a link to revert the email change is risky:

  • A link/GET request should never have side effects as security solutions might load it before the user ever does -> The link will have to lead to some kind of confirmation button
  • Reverting the email is not sufficient as the password is also likely changed by the hacker, so the user will have to go through the password recovery steps
  • You created the problem of tracking and invalidating links and emails
  • Audit logs will be hard to follow

It will be simpler and safer to send a "freeze my account and chat to support" link instead. Support can then validate some additional info.

Alternatively, request proof of access to the original email address (via a link in email) before allowing it to be changed. And force people who have lost access through manual support with additional validation.


Some considerations:

Changing the email address associated with an account may not be the first move the hacker makes. By only tracking changes made after the email change, you may revert to an already altered account.

You should forcibly reset the password and send a password reset link if the user reverts to a previous email. In most cases of account compromise the password you'd be reverting to is already compromised. This still doesn't allow for situations where the user's email account is compromised but there's only so much you can do without MFA already configured.

MFA is a good suggestion but if they didn't have it previously and the user's email account is compromised, not just their password, then the attacker can then stake an even stronger claim to the account. I don't really see any way around this issue (potentially geo-restrictions? Known IP is too strict as it could have changed but if the user is known to be in the UK don't let it be reset from Peru for example).

You should have a time limitation on reverting the change. Hours or a small number of days is too short, the legit user might not be available to reclaim their account. A few weeks to a month sound reasonable to me. Longer than that and it's going to be more of a pain to track every change and runs a higher chance that someone compromises their email account and "reclaims" the account.

In general, I feel like major account changes such as changing the email address should typically require the old email address to confirm before proceeding. I have, however, seen a situation where access to the old email address was lost as the account was closed, so if you go that route, you should have some process to allow for that too.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .