It's shocking to me that this type of email change swapping still works. I might have to write up a blog post explaining how to fix it permanently.
It's a fairly simple process though.
1. Create a table that tracks every email address change on the account. It can't just be a single field because once compromised, people have learned to just change the email address twice.
2. That table should contain fields for: user_id, email_from, email_to, confirm_key, reversal_key, created_at, confirmed_at, reversed_at, created_ip, confirmed_ip, reversed_ip
3. When an email change is initiated, an email should be sent to the new email address with the confirmation_key to have them verify the new email address before making the change.
4. Once verified, an email should be sent to the OLD email address notifying them of the change and including a link to the reversal_key to use if they did not make this switch, including the IP address and approximate geolocation of the IP address for some context.
5. If the user clicks the reversal link it will clear the confirmation and reversal links of every email change that came after the link that was clicked, ensuring that the original change can always be reversed no matter how many changes were made afterwards, revert the email address change and force the user to update the password. This password change screen should warn them that their account was likely compromised and strongly recommend they enable MFA (if available on the site) to prevent it from happening again.
I spent a year working on a site that dealt with a TON of fraud and phishing against the user base. This was one of the biggest issues that we dealt with, but this approach completely resolved the problem.
We actually implemented verification schemes similar to this for account holders at rsync.net.
One example:
- Destructive actions to an rsync.net account (manual deletions, account cancellation, etc.) have an "email age" flag. If someone is requesting something dangerous from a just changed email, support looks very closely at the request and sends a heads-up to both the old and new email addresses.
We also have some relief mechanisms for the occasions people get locked out of their lives by (google, et. al) - if a user can prove control over an rsync.net account by `touch`-ing filename of random hash we provide, we can start a reclamation process based on proving the ability to destroy the account anyway.
I like the email age flag. I’m probably going to write more about the work we did there, but implementing a trust score system with several inputs was very important too.
Email age wasn’t included, but definitely should have been.
It's a fairly simple process though.
1. Create a table that tracks every email address change on the account. It can't just be a single field because once compromised, people have learned to just change the email address twice.
2. That table should contain fields for: user_id, email_from, email_to, confirm_key, reversal_key, created_at, confirmed_at, reversed_at, created_ip, confirmed_ip, reversed_ip
3. When an email change is initiated, an email should be sent to the new email address with the confirmation_key to have them verify the new email address before making the change.
4. Once verified, an email should be sent to the OLD email address notifying them of the change and including a link to the reversal_key to use if they did not make this switch, including the IP address and approximate geolocation of the IP address for some context.
5. If the user clicks the reversal link it will clear the confirmation and reversal links of every email change that came after the link that was clicked, ensuring that the original change can always be reversed no matter how many changes were made afterwards, revert the email address change and force the user to update the password. This password change screen should warn them that their account was likely compromised and strongly recommend they enable MFA (if available on the site) to prevent it from happening again.
I spent a year working on a site that dealt with a TON of fraud and phishing against the user base. This was one of the biggest issues that we dealt with, but this approach completely resolved the problem.