Captcha is an easy way to implement a gated portion of your website where you would welcome humans but discourage bots. It is easy to implement Captcha and is effective against unsophisticated scripted bots. On the downside, it is not going to stop someone sufficiently motivated to circumvent it with a large-scale attack, and it can be perceived as a nuisance to authentic users.

TL;DR

Some developers have attempted to use Castle and Captcha together with the intention of saving Castle as a second line of defense on traffic that gets past a Captcha challenge. As it turns out, this results in less protection than using Castle alone. The quick explanation is that Castle does a better job of detecting sophisticated attacks when it is able to collect more data on the traffic that hits your app, especially at login.

Data From Failed Logins

Castle looks for signals and patterns across login attempts, whether the credentials are valid and therefore the login is considered successful, or if the credentials are invalid and the login attempt fails. The ability to identify these patterns is particularly important when there is a sudden change in volume, such as a pronounced spike in failed login attempts which can strongly suggest an attack. If a Captcha is in place to filter out some of those login attempts before Castle's models can analyze them, we lose out on valuable insight that could help us more quickly detect a unique attack signature and identify users that may have been compromised by the attack.

Attempts To Pass Captcha Failures To Castle

Developers have attempted to avoid this issue by passing along login failure data from Captcha to Castle, but this will in fact reduce the level of protection that Castle can provide and is not recommended. We do not currently support a captcha-specific event type, so sending a 'failed login' event when a user fails Captcha will dilute true login data, and it will be impossible to know if that user's credentials were actually valid and compromised by an attacker.

Different Kinds of Bots

Not all bots arriving at a login page attempt a login. Some may be hunting for a way to generate fake registrations. Others may be scrapers or crawlers whose purposes are unrelated to user security.

When considering Captcha and Castle at login, there two main issues when a captcha stops a bot. Either:

1. There is no way to know when a bot is blocked because there is no feedback event from a Captcha failing or not being attempted
2. There is no way to know the intentions of the bot. It could be a page scraping bot or a spam registration bot, neither of which are related to user security. So treating them as a 'failed login' could throw off the models that are designed to identify bots focused on attacking users vs bots that are aimlessly page scraping, etc. As a result, this can cause us to see far more "attacks" than what is actually associated with user login security

Security Workflows

When used properly, Castle enables you to introduce the right level of friction when a threat is detected.

When Castle returns a recommendation of 'Challenge' at login, we encourage issuing an identity-based step-up auth measure, such as email code verification or 2FA if available. A 'challenge' verdict hints that there is something suspicious about this device as related to this user's behavioral and access norms, meaning it may not be operated by the account owner. It is not just hinting that it is a bot. Many challenge verdicts are on fully legitimate browsers, and not bot related at all. In this case, a Captcha would not be sufficient for a "challenge" response as it could very likely be a human on the other side of the device.

Castle can also return a recommendation of 'deny' when you should block the malicious user or bot (even when correct credentials are provided). In addition to blocking malicious logins, Castle would have been able to identify whether a user's credentials had been compromised, triggering account recovery workflows where the user can reset their password and prevent an attacker from being able to attempt future logins.

In contrast, with Captcha as the first line of defense at login, an attacker can continue changing their tactics, and can eventually get past the captcha (it's not terribly hard with tools on the market today). Or in the case of a manual attack, the captcha won't provide a defense.

So while captcha is an ok tool for keeping basic, scripted bots away from a form, if you know you're already being targeted by large scale attacks, the captcha will only make it harder for ML tools to build up their models around advanced attack detection. And for Castle specifically, would prevent us from being able to tie an attack to an actual user, and help them recover their account.