Responding to Account Takeover

Ravelin will provide login specific responses to combat account takeover through our recommendations returned via /v3/login. The actions we return are BLOCK, WARN or PERMIT. The recommendations are configurable and can be easily adjusted.

As part of countering ATO, you may want to introduce different levels of friction into the user journey. The document below outlines some possible friction or functionality you can put in place focused on login. It also gives an overview of our recommendations in relation to the ATO specific responses. The options you want to put in place may depend on how you have your thresholds configured and how you want to balance the potential impact on conversion.

If you would like to read more details about response and the API generally, please review the API documentation for v3/login.

Notify Users of Suspicious Activity

Using the change detection response we provide, you can email or SMS users when a new device or IP location (to country level) is detected at login or if the email, password, phone, delivery or billing address changes. Please note, a new device will be detected every time someone clears their cookies for customers logging in via browsers.

We advise that you design any notifications based on the login patterns viewed within your data - for example, you may find that some changes create too much noise but are not necessarily good indicators of ATO.

Notifications like this are widely used by companies like Netflix, Google, Apple and many more to alert customers to unusual behaviour on their account. The email notifications usually include an option to report if the activity was not legitimate. We provide a verification URL within our response so you can let us know if the customer does this - this is important for us as it can provide labels for analysis and machine learning.

Full developer documentation available here.

Verification Codes

You can send a verification code to users where the login is deemed to be suspicious via mobile (if you have verified numbers) or email. The user then needs to use this code to complete login.

As part of this, you may need to check if the phone number or email has been changed very recently. This is in case you need to consider sending it to the previous number or email if there is a chance that a fraudster has accessed the account and updated this information already.

We would advise that verification codes are used when we return a WARN on a SUCCESSFUL login event only.

Push Notifications

For apps, you could use push notifications to get users to confirm suspicious login events or account changes.

We would advise that push notifications are used when we return a WARN on a SUCCESSFUL login event only.

Force a Password Reset

You could force a password reset by notifying the user that there has been suspicious login activity and prompting them to change their password.

We would advise that a password reset be used when we return a WARN or BLOCK on a SUCCESSFUL login event only.

Remove Saved Card Details

If a login is suspicious, you could consider removing any saved card details from the account. However, it’s important to note that this won’t stop the attack - it just mitigates the risk of a direct cost to the customer. It’s worth noting that some attackers contact customer support to get vouchers or credit for recent orders, which you don’t need saved card details to use. Attackers can still sell the account on, use stolen card details to make a purchase or scrape other personal information out of the account. Fraudsters can therefore still monetise the attack, regardless of whether there are saved card details or not.

Captcha

Many companies introduce some form of CAPTCHA challenge at login. Targeted CAPTCHA could be introduced to add friction to login where the login is already deemed to be suspicious e.g. if we returned a response of WARN on either SUCCESSFUL or FAILED login events. Alternatively, CAPTCHAs could also be used when we return a BLOCK on either SUCCESSFUL or FAILED login events. However, it’s worth noting that solving CAPTCHAs can be automated fairly easily so this is not the most effective way to reduce ATO.

Expose Login Activity to Users

Companies like Google and Microsoft expose recent login activity through security settings. Users are then prompted to flag any login events that are not legitimate. This may be overkill for many companies, especially if you choose to notify users of suspicious activity.

Ravelin responses

We return three recommendations in our response via /v3/login; BLOCK, WARN or PERMIT. The thresholds for the recommendations are configurable and can be easily changed. They should only be changed following detailed analysis to understand the impact to customers. Our investigations team can provide support on this front.

The section below runs through how we would advise each recommendation be handled. Please note, it is important to consider what actions to take on SUCCESSFUL and/or FAILED login events as we will return a response for both. During attacks many customers may be targeted unsuccessfully - triggering certain actions like password resets on unsuccessful events in this case could lead to a poor customer experience.

Block

If we return a BLOCK response, we advise that you do not allow the login and show a generic error message which does not explain why the user was prevented from login. We will only return a BLOCK response when a login is considered highly suspicious. Alternatively, you can invalidate the current password, force a password reset and reclaim the account.

Warn

If we return a WARN response, we advise that you allow the login but add in some friction (examples above). Generally, we would recommend that you use verification codes (preferably via SMS) in response to a WARN.

Permit

The user should be able to login without an issue - no action required.

Breached Credentials at Login

Ravelin also combats account takeover by checking if a user’s credentials appear in our breached credential database. Our /v3/login response will indicate within the credential status object whether or not the username and password appear in Ravelin’s breached credential database.

  • If the credentials entered do not appear in our breached credential database we will return the following on the credential status object:

    usernameCompromised:false
    passwordCompromised:false

    If the response is PERMIT and the credential status is FALSE for both username and password, we suggest you allow the login - no action is required.

  • If the email or username entered appear in our breached credential database but without a password, we will return the following on the credential status object:

    usernameCompromised:true
    passwordCompromised:false

    If the credential status is only true for username, we suggest no action is required.

  • If the username and password entered appear in our breached credential database we will return the following on the credential status object:

    usernameCompromised:true
    passwordCompromised:true

    If the credential status is true for both username and password, we suggest you take action (see suggested actions below). Likewise, we suggest you take action if just the password is compromised.

Suggested actions for breached credentials at login

If a user is trying to login using credentials that appear in the breached database there are a number of actions you could take. However, we strongly recommend if a password is breached that the user be forced to reset their password. The user should be encouraged to change it on any other service that uses the same credentials.

  • Prompt the user via email or text to reset their password before they login
  • Force the user to reset their password after they complete their session
  • Use verification codes via mobile or email to complete the login
  • Remove any saved credit card details from the account

Breached Credentials at Registration

At registration, you can call our v2/lookup/credentials/check endpoint. We will return one of two responses, outlined below.

  • If the credentials entered do not appear in our breached credential database we will return the following on the credential status object:

    usernameBreached: false
    passwordBreached: false

    No action is required if we return false.

  • If the email or username entered appear in our breached credential database but without a password, we will return the following on the credential status object:

    usernameBreached:true
    passwordBreached:false

    If the credential status is only true for username, we suggest you take no action.

  • If the credentials entered do appear in our breached credential database we will return the following on the credential status object:

    usernameBreached: true
    passwordBreached: true

    If the credential status is true for both username and password, we suggest you take action (see suggested actions below). Likewise, we suggest you take action if just the password is compromised.

Suggested actions for breached credentials at registration

If a user is trying to register using credentials that appear in the breached database, we advise that you do not allow the user to set the password at registration.

Breached Credentials at Password Update

During a password update (e.g. forgot password, password change), a client can call our v2/lookup/credentials/check endpoint. We will return one of two responses, outlined below.

  • If the credentials entered do not appear in our breached credential database we will return the following on the credential status object:

    usernameBreached: false
    passwordBreached: false

    No action is required if we return false.

  • If the email or username entered appear in our breached credential database but without a password, we will return the following on the credential status object:

    usernameBreached:true
    passwordBreached:false

    If the credential status is only true for username, we suggest you take no action.

  • If the credentials entered do appear in our breached credential database we will return the following on the credential status object:

    usernameBreached: true
    passwordBreached: true

    If the credential status is true for both username and password, we suggest you take action (see suggested actions below). Likewise, we suggest you take action if just the password is compromised.

Suggested actions for breached credentials at password update

If a user is trying to update their account using credentials that appear in the breached database we advise that you do not allow the user to use the password at time of update.

If you prompt the user to change their password at login, registration or password update, we suggest informing them that the password has been compromised and that they should change it elsewhere. Please see below for example text:

‘The password you are attempting to use is in a breached credential database. This means the password has been seen online as a result of a data breach on another service. To secure your account, please choose another password. If you use this password anywhere else, we strongly recommend that you change it.’

Reclaiming an Account

For full details on how to reclaim an account, please read our developer documentation. In cases where an account is reclaimed by the legitimate owner you need to notify us that the account has been secured. This will prevent the account from being blocked due to activity that happened while the account was compromised.

We recommend telling us about the account reclaim either:

  • After the legitimate customer has reset the password and the account can be considered secure
  • If you have force reset the password to something new and the account can be considered secure