Protecting Shoppers from Account Takeovers

This guide describes how the Shopper Login and API Access Service (SLAS) and SLAS Admin APIs give you new tools for protecting shoppers from account takeover (ATO) attacks. An ATO is a form of identity theft where an attacker gains unauthorized access to a user's account credentials. According to the SIFT report from 2019 to 2021, consumer ATOs increased 307%.

The most harmful and disruptive issues experienced by shoppers and merchants can often be traced back to ATOs, including:

• Fraudulent orders
• Theft of gift cards, loyalty points, or anything of value
• Exposure of personal information
• Spikes in customer complaints and support cases

To make matters worse, one ATO can lead to another because the same credentials are often reused across multiple websites. The credentials that someone uses on your storefront could potentially be used to log in to their email provider, exposing them to even more risk of identity theft. And the reverse is also true: if the user’s credentials for the email provider are exposed in a data breach, those credentials could potentially be used to log in to your storefront. According to the SIFT report from 2019 to 2021, 65% of people globally use the same password for every account they own.

Because user credentials can be exploited for a wide range of malicious purposes, they have become a valuable commodity for bad actors. On the dark web, huge collections of credentials are bought, sold, and traded every day. And just as often, they’re released in the open.

To reduce the risk of ATOs, most merchants have implemented broad security measures, such as requiring strong passwords and offering multi-factor authentication. Although these security measures are effective, they haven’t eliminated the threat of ATOs altogether. Bad actors remain incentivized to find other vulnerabilities, such as credential reuse, to exploit.

With the SLAS and SLAS Admin APIs, you can measure not only the strength of passwords but also the quality of credentials and passwords based on their level of exposure on the dark web. As you would expect, weak passwords and poor quality credentials are often a precursor to ATOs. With the SLAS APIs, you can start monitoring ATO-related metrics, establish a baseline, take action, and track the impact of your action over time.

In addition to shopper-level data, the APIs also provide aggregate data so that you can track the overall progress of your ATO risk reduction efforts.

The SLAS API and SLAS Admin API both offer endpoints for assessing the quality of a particular shopper’s credentials. The credential quality endpoints can tell you how many times the shopper’s username and password have been exposed on the dark web. To look up the number of exposures, we’ve partnered with a security firm that specializes in monitoring data breaches and dark web activity. Our partner offers services that are similar to sites like haveibeenpwned.com, but their records are more extensive and updated more frequently. Both SLAS APIs offer a /cred-qual/ endpoint that returns the following data about a given user:

One particular piece of data is worth highlighting: atoScore. The ATO score combines several different measures of credential quality into a single number. The ATO score is based on the following measures that are returned along with it: credQualityMeasure, pwdQualityMeasure, pwdStrengthMeasure, atoLastDatetime, and lastCredcheckDatetime. Each measure is assigned a different weight when calculating the ATO score.

The ATO score uses the following scale of ATO likelihood from 1 to 10+:

• 0–1 extremely unlikely
• 2–3 highly unlikely
• 4–5 unlikely
• 6–7 likely
• 8–9 highly likely
• 10+ extremely likely

Let’s look at two examples where data from the SLAS APIs can help you decide what actions to take to increase credential quality and reduce ATO risk. Both examples assume that your shopper credentials are handled by Salesforce B2C Commerce (if a third-party identity provider is being used, this feature is not available) and that your SLAS configuration is complete.

Example 1: Login Flow Check

Every time a shopper logs in, your headless app can make a request to the credential quality endpoint of the SLAS API. (The main SLAS API is designed to meet the performance requirements of shopper flows, while the SLAS Admin API is not.) You supply the shopper’s username as a query parameter. If the value of credQualMeasure in the response is greater than 0, you notify the shopper of their exposure and warn them that they can only log in 3 more times before a password change is required. If the credQualMeasure is 3 or greater, you can require them to reset their password immediately.

Here’s an example response from the credential quality endpoint where the shopper’s credQualityMeasure is greater than 0:

Example 2: High ATO Score

When the shopper logs in, the credential quality endpoint returns an ATO score of 9. A score that high indicates that it is highly likely that the account has been taken over, so immediate intervention is required. The user’s password is reset immediately.

Here’s an example response from the credential quality endpoint:

The credential quality data that is returned by the endpoint explains the high ATO score. For starters, both credQualityMeasure and passwordQualityMeasure are greater than zero. But an even bigger contributor to the high ATO score is the value of atoLastDatetime.

The value of atoLastDatetime tells us that the last time an ATO-related event (such as a credential stuffing attack) was detected was back in October 2021. And the value of lastCredChangeDate tells us that the user last changed their credentials in May 2021. Because the ATO-related event was detected after the last credential change, it is highly likely that the ATO attack was successful. The large gap between the two dates and the elevated values for the other credential quality measures all contribute to the high ATO score.

According to the atoScoreHistory array, today's high ATO score is part of a trend: it has been steadily increasing over the last three assessments (5, 6, and now 7).

Example 3: Monthly Uplift Campaign

Once per month, you make a request to credential quality endpoint of the SLAS Admin API. (The SLAS Admin API is designed to meet the lower performance demands of infrequent administrative tasks, while the main SLAS API is designed for the higher performance demands of shopper flows.) You supply the username of each registered shopper as a query parameter. If the returned value of credQualMeasure is above a certain threshold of your choosing, email the shopper to notify them about their exposure and suggest that they change their password.

The SLAS Admin API also offers endpoints that help you track the effectiveness of your ATO reduction effort across an entire B2C Commerce tenant with several different metrics, including:

• loginCount: count of total logins
• checkCount: count of credential quality checks on each login
• credsOkay: count of credentials that are not compromised
• repeatedCompromisedUse: count of shopper logins with compromised credentials
• credsCompromised: count of credentials that are compromised
• credsCompromisedPercent: percentage of credentials that are compromised
  • Formula: credsCompromised / checkCount
• exposure1, 2to4, 5to9, 10plus: count of dark web exposures
• pwdsOkay: count of passwords that are not compromised
• pwdsCompromised: count of passwords that are compromised
• pwdsCompromisedPercent: percentage of passwords that are compromised
  • Formula: pwdsCompromised / pwdsOkay + pwdsCompromised
• avgPwdStrength: average of password strength across all tenant credentials

We recommend that you query the SLAS Admin API daily to include these metrics in back-office dashboards and reports.

Based on your monitoring of ATO-related metrics, you can choose from several possible interventions, such as:

• Warning shoppers of weak or compromised credentials
• Forcing a password reset
• Requiring two-factor authentication (2FA)
• Suspending an account until the password is changed
• Offering a passwordless authentication method

Most of these interventions are self-service, effectively automating the ATO reduction effort. For interventions that interrupt the login flow, you can implement them based on thresholds, as we described earlier in the login flow check example. Our goal with the ATO-related metrics in the SLAS APIs is to provide you with the data you need to choose the right interventions at the right time and monitor their effectiveness as part of an overall ATO-reduction effort.

The following table summarizes all the available endpoints related to ATO reduction. More endpoints will be added in future releases, so watch this space!

For full implementation details, see the API specifications for the Shopper Login and API Access Service (SLAS) and SLAS Admin.