Account takeover is an attack where bad actors gain unauthorized access to the victim’s online accounts, such as their email or bank account. Attackers can steal data from the account and execute other kinds of attacks, despite additional identity factors (2FA/MFA).
This describes how you can protect your user accounts against these attacks using Transmit Security detection and response services.
Common attack vectors for account takeover include:
- credential stuffing using stolen credentials (e.g., from a data breach)
- bots or automation tools used to execute brute-force attacks or credential stuffing
- device takeover using remote access (e.g., RDC or malware)
- social engineering to obtain personal info or trick users into providing remote access
- session/cookie hijacking to perform unauthorized actions within the user's session
The first step to preventing account takeover is to provide Transmit with the telemetry required to continuously assess risk for the given context, and to identify trusted users. Report sensitive actions as the user requests to perform them during risk moments.
To report data and actions:
- Add the Detection and Response code snippets, ideally on each page of your website. This will automatically provide telemetry to our machine learning engine—such as device, network, and other context data used to continuously assess risk.
Set the (authenticated) user as soon as possible to add the user context for all subsequent events of the session. This will also be used to create and update a behavioral profile of the user, so we can detect anomalies in the future. The user can either be set using the
initialize()call, or after authentication using the
setAuthenticatedUser()call. In both cases, it should be set only after you've fully authenticated the user (including, for example, any 2FA that was required). Make sure the user identifier you use doesn't contain any personal information.
actions that are relevant to your use case using the
triggerActionEvent()call. For example, report
password_reset, and all other relevant actions .
When a user logs out or a user session expires, make sure you call
clearUser()so they are not associated with future actions.
See Quick starts for integration steps and code snippets. Once you complete this step, you can already see how it works by running your app, requesting to perform a sensitive action that your snippet reports, and then going to the Admin Portal to see the recommendations associated with the action. In the next steps, you'll learn how to fetch recommendations yourself and act on them.
For every action you report, use our Recommendation API to fetch our recommendation.
When requesting a recommendation, it's best to specify the user identifier (
user_id) associated with the account the user wants to access. Even if the user has not yet been authenticated (e.g., in the case of a
login action) and hence was not set using the SDK, this enhances our detection capabilities. For example, we can compare the behavior profile of the unauthenticated user against the profile of the specified user in order to detect behavioral anomalies. Specifying the user also helps us determine whether the same device is being used to access multiple accounts.
Based on the recommendation we provide, you can determine the risk level of the action in the given context, choose an appropriate risk mitigation strategy if needed, and build trust for the user, device, and network. You can also send the recommendations to your analytics systems for further persistancy and offline analytics.
See Quick starts for API integration steps and code snippets.
There are different types of recommendations that you can get (see Recommendation types). If you receive a
challenge recommendation, you should mitigate the risk by giving the user a challenge to perform. Choose a challenge that's suitable for the action. For example, for a
login action, consider a second-factor authentication. We recommend using a strong biometric-based method since it provides the best user experience and is often the most secure.
See Challenges for our suggested challenges based on your use case.
Each recommendation includes the reasons for the recommendation, which indicate the risk signals that were used to detect suspicious activity. For example,
DEVICE_COOKIE_REUSED may indicate session hijacking,
PROFILE_DEVICE_NEW means the user is likely using a new device, and
DEVICE_SUSPICIOUS_ATTRIBUTE may indicate device spoofing.
Recommendations not only allow you to mitigate risk, they're also used to build trust. If you receive a
trust recommendation, you can trust the activity, extend the session, and lower friction.
The goal is to keep great customer experience, so reduce friction whenever you can in high-trust scenarios.
Leverage our authentication and identity management capabilities for account protection scenarios: