Self-serve Account Takeover Protection
Heya,
I wandered across “Automatically Reversing Account Takeovers”, by Barry Jones, which outlines an ingenious way to prevent some damage from a CIAM account takeover.
I wanted to walk through the problem and the solution he discusses.
Self-Service Registration
Let’s talk about how self-service registration works to get a customer or user access to your application.
When a user signs up, they provide a login identifier you verify, typically a phone number or an email address. This is paired with a password. These credentials are used to allow further access to the application, data, and functionality in the future.
(I’m ignoring magic links, federation, passkeys and other login methods to keep things simple.)
This login identifier can also be used to offer self-service credential reset, where a time-limited code is sent to the email or phone number. This code can be used, sometimes in conjunction with other information or processes, to reset the password associated with this account.
Self-service credential reset is a huge boon to both users, who can easily access accounts they don’t remember credentials for, and customer support, which doesn’t have to manually verify user identity.
Instead, this approach relies on ownership of the login identifier delivery mechanism, such as the email inbox, to verify the identity of the user. This is far more scalable, cheap and automated.
After A Successful Attack
If an attacker gets access to an account, one of the first things they do is change the login identifier.
Among other reasons, doing so means the victim can’t use the self-service credential reset process to regain access to your application. If they try to use an old email address to reset their password, there will be no time-limited code sent, because it is only sent to the current login identifier.
The Victim’s Remediation Options
What are the options for the victim at this point, when they have discovered that they are locked out of an application account?
It’s calling customer support and proving who they are.
This is decidedly not self-service. Even if you document and automate as much as you can of it, it can cause a tremendous support burden.
The article discusses another option.
Self-service Email Change Reversal
The article focuses on email addresses as login identifiers. But if you use phone number for your login identifier, the idea is much the same.
The process is:
Make sure you can trust your delivery mechanism. Set up DMARC, etc or use a SMTP provider that does so.
Track all email address changes; this is what allows you to revert them. It’s important to not just have
current_email
andlast_email
because an attacker can change the login identifier multiple times. The table includes other data, such as hashes of the new and old email and IP addresses and timestamps.Next, don’t change an email address until the new one has been verified. This means that any attacker must use a valid email address to access the application, as well as preventing the attacker from spamming the old address. That spam would otherwise occur, because the next step is to:
Notify the old email address of the change. Include a link to revert the email address change and a message.
That notification means that the victim knows someone tried to change their email address.
If the user meant to make the change, no problem.
If the user didn’t, they can now revert the email address change by clicking on the link.
The article lays out what needs to happen with the actual reversion process, including credential resets, cleaning up the email address tracking table, and warning the user about possible attacker access to their account.
Not Perfect
This doesn’t help if the user has lost access to the email inbox, but that’s a huge vulnerability, and why everyone should have MFA set up on their email account.
This approach helps if the attacker has gained access to your application’s account through other means (phishing or social engineering).
But it protects against the latter attack in a elegant, self-service manner.
Dan