Protecting your business against customers account takeover fraud

Introduction

Successful customer account takeovers can result in fraud, cause damage to a brand’s reputation, undermine customer confidence and result in major fines. Many incidents are the result of successful credential stuffing attacks. In such an attack, cyber criminals try to logon using username and password combinations that were stolen at third parties. If customers reuse passwords, their accounts become easy targets. In real-life we see that in a typical organization roughly 5-15% of customer accounts can be successfully breached using credential stuffing.

Password length and complexity rules will not help: the issue is not that the password is not good enough, the issue is that the credentials are known to criminals and therefore easy-to-guess for the bad guys. Rate limiting will also not help since an attacker only needs a few or just a single attempt per account.

Since more and more organizations are confronted with skilled attackers that are performing successful attacks, we get more and more questions about how to adequately protect customer accounts. In this article we take a closer look at the ingredients that are required for effective protection, and how existing services work under the hood.

Figure 1: preventing customer account takeover by blocking leaked passwords

Requirements for a quality service

To effectively protect your customer accounts throughout the account lifecycle, six requirements need to be met:

  1. Protection against credential stuffing. If a service uses blacklisted passwords only, a lot of false alarms will be raised (‘ false positives’). In fact, such a product protects against password spraying (try combinations of usernames and popular unrelated passwords), not against credential stuffing (try combination of usernames and passwords that were leaked for the specific accounts).
  2. Quality data. If the credential checks are done using poor quality data, leaked credentials will not be flagged as such, giving a false sense of security (‘false negatives’).
  3. Credential check at account creation. If the email and password combination has already leaked, the password should be refused. This way future incidents will be prevented.
  4. Credential check at password change. Same as requirement 3, but triggered by a password change of an existing account, instead of the creation of a new account.
  5. Credential check after new data becomes available. Passwords that are used by customers might have been safe at the time of the last password change. That might change when new data leaks surface. To determine if yesterday’s passwords are still safe against today’s threats, a new and full check needs to be performed. This check should over all customer accounts, including accounts that are not frequently used and accounts at rest (active but unused).
  6. Central management. For proper detection, follow-up and reporting, threat data for monitored accounts needs to be available in a central location. Using this central location, organizations can integrate events in their issue tracking and monitoring solutions.

If the requirements are not all met, accounts will be at risk.

An overview of well-known services

Although at first sight available services look similar, they are in fact very different. Let us take a closer look at our solution and services that were brought to our attention.

Figure 2: service charateristics

BreachCheck (Scattered Secrets)

Scattered Secrets focuses on data quality. Our core business and competence is being best in class in password cracking, and delivering unique and quality content. To do this we are using advanced custom build hardware and smart strategies. Quality data allows us to offer quality protection against credential stuffing. Using minimal knowledge protocol APIs, credential leakage can be checked at every point in the account lifecycle. All six requirements are met.

Consumer Protection (SpyCloud)

According to SpyCloud, “SpyCloud checks your consumer credentials against the largest repository of Recaptured Data in the world [..] and alerts you to exposures that could put your consumers at risk.” Requirement 1, 3, 4 and 6 are met. The status of requirement 5 is unknown based on public statements. concerning data quality, SpyCloud is not a true password breach notification service resulting in a limited protection level for requirement 2.

Password Checkup (Google)

In an excellent paper, Google explains the design and implementation of Password Checkup. Password Checkup uses pre-computed breach data that is hashed and encrypted using a specific format. Because of the specific format, Password Checkup cannot be used to verify if accounts are affected by new data if any other hashing format is used. Password Checkup can also not be used to centrally manage a customer population, since it is an end-user product. Requirement 5 cannot be met for non-Google products. Furthermore there are no references claiming that Google actively cracks passwords, resulting in a limited protection level for requirement 2.

Credential Guard (Auth0)

According to Auth0, “Credential Guard protects applications and users from account takeovers by providing actionable intelligence on passwords exposed in a data breach.” In other words: if one of the used passwords is in a blacklist, it is flagged. There is no relation to the account name or email address. So accounts also get flagged if the password is used by somewhere else on the internet. Since there is no context, this mechanism does not protects against credential stuffing. Only the sixth requirement is met.

Pwned Passwords (Have I Been Pwnd)

Pwnd Passwords is a huge password blacklist. So this product does also not protect against credential stuffing. Obviously the same is true for all products that are based on Pnwd Passwords, like for example 1Password Watchtower, Firefox Monitor and Okta PassProtect. Only the sixth requirement can be met, based on an organization’s specific implementation.

Azure Active Directory Password Protection (Microsoft)

According to Microsoft, Azure Active Directory Password Protection is based on a “global banned password list” and optionally a “custom banned password list”. This product does not protect against credential stuffing. Only the sixth requirement is met.

Password Monitoring (Apple)

According to Apple, “Password Monitoring is a feature that matches passwords stored in the user’s Password AutoFill keychain against a continuously updated and curated list of passwords known to have been exposed in leaks from different online organizations. If the feature is turned on, the monitoring protocol continuously matches the user’s Password AutoFill keychain passwords against the curated list.” So again a product based on context-less passwords. Password Monitoring can also not be used to centrally manage a customer population, since it is an end-user product. None of the six requirements is met.

Data protection & privacy

We understand that you do not want — or are even allowed — to share your customer data with third parties. That has been taken care of. We use a minimal knowledge protocol. You do not share client emails with us: instead we use pseudonymized identifiers. You do not share client passwords or password hashes with us: instead we use encrypted hashes. We do not share personal data (passwords) about your pseudonymized customers with you: instead we share metadata. Besides that we do not want to be an additional dependency for your organization, this is required in European Union countries by law.

Integration

Scattered Secrets BreachCheck can be integrated in a portal as a real-time check using our API. This offers pro-active protection. This requires code updates in the portal application.

In some cases code changes might practically be challenging, especially if multiple parties are involved. As an alternative, we offer stand-alone checks. Stand-alone checks are reactive, via none-time critical path. This option does not require code updates in the target application and does not introduce new dependencies for the target application: just export and prepare data for a scheduled out-of-band check. Even though this is a reactive check, effectiveness can be high by using a high frequency of checks. This type of check can also be used for incident response: using our data we can quickly run a check on all customer accounts while you are under attack, to determine which accounts can be breached by a skilled attacker over time. With us outpacing the attacker, this allows you to preventively block the affected accounts before the attacker can perform account takeovers.

Bonus

By using Scattered Secrets BreachCheck you can protect your business against customer account takeover fraud. As a bonus, you can provide your customers that reuse credentials with valuable advice to change the credentials at all third party accounts. This can help them to eliminate online threats. Added value for your customers!

Proof of Concept

Do you want to verify the exposure of your customer accounts? You can! You can compile a test dataset and we will provide you with the results. Do the same for all other services you are interested in and just compare our results with the competition’s data. Choose the best!

Conclusion

For best customer account takeover protection, use Scattered Secrets BreachCheck. Our service can be fully integrated for real-time protection, or used as a stand-alone check that does not require application code updates and does not introduce new dependencies. Please let us know if you have additional questions. And don’t forget to check if your passwords are breached.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store