Layer 1 copy

Goal of this Guide

The goal of this guide is to help you understand the Account Takeover Prevention (ATO) product and how to integrate it into your site or application. When properly integrated, the product will help you identify risky logins so that you can protect your users from having their account hijacked.

Send Data about Your Users to Sift

To integrate the product, you’ll need to send information about your users before, during and after login. It’s important to send this data because it enables Sift to detect risky patterns of behavior. Sift maintains a set of client libraries to make sending this data easier.

Add the Sift Javascript Snippet to your site

Include the Sift JavaScript snippet on your webpages pre and post login. This should be included to both the desktop and mobile versions of your website.

Add the Sift Mobile SDK to your apps

Include the Sift iOS SDK to your iOS app. An Android SDK is currently under development.

Send Account and Login Events to the Sift API
Account

Whenever a user signs up for an account or makes changes to their existing account, you should send a record of that to Sift. Changes to account are often important to capture to detect accounts that have been compromised.

Login

Whenever a user attempts to log in to their account, send a record of that to Sift. Send both successful and failed logins. Also, send a logout event whenever a user actively chooses to logout.

NOTE: You must send the Session ID with the login event for ATO to work properly.

Verification

In response to a risky login, you’ll likely want to verify whether the user is who they say they are. If your login flow contains a verification step, sending this information to Sift is very useful as it gives additional feedback to our systems.

Send Use-Case Specific Events to the Sift API
Orders and Payments

If your service allows users to purchase items or make financial transactions, you should send:

Content Creation

If your service allows users to create content - e.g. listings, profiles, postings, rentals, etc - for others, you should send:

Using ATO Risk Scores

After sending a login event for a successful login, Sift can send back a risk score for that login which will tell you how risky the login is. This will help you decide whether any further action is required for this user login. To receive a risk score with a login, just append "return_score=true" as query parameter to the $login event that you send. Here’s a link to more information on receiving risk scores synchronously with events.

Upon receiving the risk score, you can then decide whether any further action is required. For higher risk logins, you may want to do one or more of the following:

  • Sending an email notification to user that there is a login from a new device or location. These emails often include a means for your user to let you know if it was not them.
  • Sending a one time passcode via SMS, email, or app that a user must enter after login to further verify themselves. This second factor of authentication is useful if the user’s login is significantly different than past logins.
  • Restrict access to certain sensitivity information (eg bank info, user details) or limit certain sensitive actions (eg changing payment information, changing shipping address, withdrawing money, etc) until the user verifies themselves or logins from a previously used device.

For any login where you choose to send a passcode as a challenge, you should tell Sift both when you send it and the final outcome(ie pass or fail). With this information, Sift can better learn about which patterns are risky and we which are not. To send this, you will use the $verification event. Learn more about using the $verification event.

Making Decisions on Users

When you identify users who’ve had their accounts compromised, you can take action directly from the Sift Science console. You can link Sift Decisions in the Console (eg “Account Compromised”) to any account reset or recovery processes you have in your system.

The typical pattern we recommend is:

  • Your analyst identifies a compromised account via the Sift Console. They’ll apply an “Account Compromised” Sift Decision and select the specific logins that were from the attacker. By flagging specific logins, Sift can learn the attack patterns unique to your account and better protect you going forward.
  • When an analyst clicks the Decision button in the console, Sift will send a webhook to your system. In response to the webhook, you will kick off an account recovery process on your side. This will likely involve cancelling all active sessions and forcing the user to reset their password.
  • Once the user has reset their password, you will send an “Account Recovered” Decision to Sift. This can be done via the Sift Console or by using the Decisions API. The Decisions API allows you to send Decisions to Sift from your system without using the Console.

Any questions? We're happy to talk it through.