Bears, mice, and moles aren't enough: a better approach for preventing fraud

Fraud prevention is a never-ending battle, and seasoned fraud teams almost always describe it in terms of what I call the three animal analogies:

1. Whack-a-mole: ban one account, and another pops up. It can be difficult to stop a bad actor, because of the dynamic of…
2. Cat-and-mouse: in general, fraud is adversarial; you can’t just solve it because the attackers are evolving, too.
3. You don’t need to run faster than the bear: luckily, fraudsters are looking for the path of least resistance. You can add controls that aren’t perfect, but lower the attacker’s ROI enough that they move on to easier targets.

I love these analogies. They’re colorful and accurately capture some of the flavors of our work.

At the same time, they’re not very useful. In the last year, we’ve observed increasing fraud activity, from low-effort automated spam (made easier by LLMs, unfortunately) to sophisticated account takeover attacks from residential botnets. What am I supposed to do, whack faster? Ask the bear to go chase someone else instead?

To actually improve fraud prevention, we need to be able to evaluate our current state and potential future options in a meaningful way. At Stytch, we have developed a high-level framework for fraud prevention, and we use it to guide our internal fraud strategy as well as our Device Fingerprinting product.

The Stytch fraud prevention framework

At Stytch, we evaluate four main areas for our fraud prevention framework:

1. Signal gathering: Capture information about user activity.
2. Decisioning: Given that information, decide what to do.
3. Enforcement: Given the decision, add or reduce friction in the user's journey.
4. Analysis and feedback loop: Observe, iterate, and improve detection and controls based on real-world outcomes.

It may seem obvious to break down the fraud prevention process in this way - it’s very similar to John Boyd’s OODA loop concept - but it gives us a common language and separation of concerns.

If there’s a fraud problem, it’s because we are falling short in at least one area. We should be able to evaluate our capabilities across each of the areas, and identify which area(s) to focus on.

The framework in action: escaping whack-a-mole for sophisticated credential stuffing attacks

Let’s take a whack-a-mole example. At Stytch, we’ve seen sophisticated credential stuffing attacks: an attacker gets a list of usernames and passwords from public data breaches, and tries using them to login to different websites, knowing that users often re-use passwords.

One traditional defense against credential-stuffing is to use IP-based rate limits and bans. But some attackers use malware-powered residential botnets to proxy their traffic, cycling through thousands of IP addresses. If you ban an IP address, they’ll quickly switch to a new one; and since attackers are using the compromised computers of real people, you might also ban legitimate users in the process.

Attackers can easily buy access to residential IPs, using malware to hijack your computer. These six VPN apps were malware used in the “911 S5” residential botnet, which compromised over 19 million IP addresses in 190 countries. (FBI notice: fbi.gov/911S5)

In the language of our framework, the enforcement is ineffective; high velocity of requests is a good signal of abuse, but it doesn’t precisely or stably identify the attacker. We can automate the IP-based enforcement to limit the damage, but it probably won’t stop the attack. We can try adding a CAPTCHA, but paid CAPTCHA-solving services and multi-modal AI limit their effectiveness, too.

So what’s left? Gather more signals, or make better decisions with our existing signals.

In our login flows, we want real humans, rather than automated bots like the ones in the attack. Using Stytch Device Fingerprinting, we can collect more signals and warning flags based on browser and device characteristics. For example, if a request sends the user agent of Safari on MacOS, but actually has the attributes of Chromium running in a VM, the request is flagged for deceptive behavior - far more likely to be a bad actor.

In other words, we get better signal gathering and decisioning from Device Fingerprinting. And that means we can implement enforcement based on abusive fingerprints, which are stable no matter how many IP addresses the attacker controls. That’s one way to whack all the moles!

How the framework shapes our Device Fingerprinting product

Stytch Device Fingerprinting is intentionally focused on the signal gathering and decisioning areas of the framework. Just take a look at the breakdown from our documentation:

Why? As much as I’d love to do it all, Device Fingerprinting only captures device and browser information, which is not the full picture. For example, credential stuffing attacks almost always have a high rate of attempts to login to accounts that don’t exist at all - that’s data known to the authentication system, but it doesn’t show up at all in the attributes that Device Fingerprinting measures. Or in scam and spam detection, a key signal is the actual content of a message being sent - that’s not visible to Device Fingerprinting either.

So, we are not trying to build a perfect black-box oracle here. That would be a lovely experience when it works, and a nightmare when it doesn’t. We don’t want your support team to have to explain to customers, “Sorry, the mystery machine said your risk score is 0.71 and I don’t know why either.”

Instead, we want to be your trusted partner in the endless fight against fraud. At Stytch, we are doing the tedious work of keeping up with browser and platform updates, detecting the latest deception techniques, and understanding what legitimate users really look like. This is the cat-and-mouse game that we do play, so that you don’t have to.

And every time you look up a fingerprint, we will recommend an action - but you’re in control of the decision and final enforcement method. You have the best view of the situation and understand the context of your business - who else will do it?

This is just the beginning

Every day at Stytch, I marvel at how smart and motivated attackers try to extract value from us, our customers, and the world at large. Our fraud prevention framework is just a starting point, one lens to look at the world. Zooming in just a little, we can talk about fraud vectors vs. abuse outcomes, the concept of a “kill chain”, the swiss cheese model, and so on. There is so much more than the three animal analogies.

If you’re tackling fraud problems, automated or otherwise - please reach out. I’d love to hear about your situation, what’s working, and what’s not.