A Layered Approach to Bot Detection and ATO Prevention

Deploying successful strategies for mitigating attacks against your users and applications means thinking about different kinds of attacks, and where to best tackle them in your software stack.

In this blog post, I’ll talk about a layered approach to security, and how installing Castle in these layers gives you a single solution that is not only exceedingly effective from a security standpoint, but also reduces friction for your end-users.

As the diagram below indicates, it’s helpful to think about two major layers in user and account defense: a “pre-auth” layer and a “post-auth” layer.

Pre-Authentication (pre-auth)

At this stage, the application does not know who the user is. The request might be a registration attempt, in which case there is no existing user to authenticate. Or, it might be an authentication attempt that includes a username and password, but the application has not yet validated the username and password combination against an identity store.

At this stage, your software stack should implement bot mitigation strategies by looking at the posture of the device and the ip address for indications of bot activity. It’s also a good place in a registration flow to look for bogus email addresses and phone numbers.

Using an Edge Solution

Because bots can generate such a large amount of traffic, it makes sense to set up an “edge” solution to accept all of these requests and evaluate them before allowing them to proceed further into your application infrastructure.

More specifically, this means that POST requests to your /register and /login endpoints should be received by a CDN (Cloudflare or Cloudfront, for example), and the CDN should have the ability to incorporate the Castle risk engine to assess whether the request is coming from a bot.

Your relatively inexpensive edge infrastructure can thus “soak up” bot traffic, saving you infrastructure expense and keeping bots that much further away from more valuable assets.

However, it’s not required that this layer live on the edge in your particular deployment; what’s important is that you intercept and inspect requests before sending them on to your /register and /login endpoints.

It’s important to note here that some bot-detection solutions rely on a CAPTCHA at this stage to determine whether a specific request is coming from a bot. While this approach can be effective, it also introduces friction into the experience for your users. Castle’s approach does not rely on a CAPTCHA-like solution.

Also – Castle’s solution at this stage is “identity aware”: as your real users successfully authenticate, Castle learns to associate their usernames with their device contexts, and Castle then incorporates this historical data into its recommendation about whether to allow, deny, or challenge a particular request.

Post-Authentication (post-auth / in-app)

The post-authentication layer, or “in-app” layer, is when the application – in the context of an authentication request – has determined that the username and password combination supplied in the request is valid.

Put another way, the pre-auth layer is where bots get filtered out; the post-auth layer is where you need to assess whether a human user is using stolen credentials in an ATO attempt.

So, at this point, assuming that you’ve deployed bot detection at the edge, the bot requests have been filtered out, so the primary concern is a human user who has somehow acquired another user’s valid credentials – through the dark web or phishing, for example.

With these requests, again, the app will send the supplied username and password to its identity store and receive a “valid” response in return. However, before responding to the request, the app will send the request to Castle for assessment.

Castle will respond with a risk score and a verdict (“allow”, “deny”, “challenge”) that the app can use to construct an appropriate response to the authentication request. It’s important to note here that when Castle renders a “deny” verdict, the application can respond to the request just as it would as if the user had entered an incorrect password – thus not letting the attacker know that they have actually submitted a valid set of credentials.

Using Castle to reinforce both layers

While it’s certainly possible to use two different solutions at the pre-auth layer and the post-auth layer, using Castle at both layers has several distinct advantages:

• one pane of glass to review and track attacks, and also troubleshoot any issues an end-user might have logging in.
• no CAPTCHA necessary
• identity awareness at both layers: Castle can track usernames and device fingerprints at both layers, thus reinforcing the accuracy and effectiveness of assessments at both layers.

Finally, while it’s not necessary to deploy your pre-auth solution at the edge, this can be a cost-effective way to handle large volumes of bot traffic.

Castle provides code examples for edge solutions such as Cloudflare and Cloudfront. You can learn more about those solutions in our docs.

*** This is a Security Bloggers Network syndicated blog from Blog authored by Tom Smith. Read the original post at: https://blog.castle.io/a-layered-approach-to-bot-detection-and-ato-prevention/