Enforcement with Device Fingerprinting

In the Stytch fraud prevention framework, enforcement is a key phase of prevention. Once we have made a decision about what to do, we need to actually enforce that decision: reduce friction for a good user, or add friction for a bad actor.

Your enforcement options vary, depending on if you're using the Protected Auth integration with Stytch frontend SDKs for authentication, or the standalone Device Fingerprinting API:

• Protected Auth (requires Stytch frontend SDKs for authentication)
• Custom enforcement logic
• Integrate with WAFs and other tooling

If you are using Stytch for authentication for B2B SaaS or Consumer Authentication, you can toggle on Protected Auth to immediately protect your application from attacks like credential stuffing and automated account creation.

Protected Auth uses Device Fingerprinting to protect sensitive events like login and password reset. When enabled in Enforcement mode, the Protected Auth SDK automatically generates Telemetry IDs and includes them in requests to the Stytch API. The Stytch API will reject any requests that receive a BLOCK verdict.

To learn more, see Protected Auth overview.

If you are using the standalone Device Fingerprinting API, you can write backend code to implement your desired custom enforcement logic.

The ideal enforcement method will vary depending on your use case, as there are trade-offs between immediate prevention, meaningful error messages, and increasing the difficulty for the attacker to understand your defenses.

Here are four common ways to do custom enforcement:

1. Block the request
2. Step-up authentication
3. Shadow-ban the action or user
4. Allow the action and log for later use

Your application can block the specific request that received a BLOCK verdict, returning an error. This is the most common enforcement approach.

The error response may be opaque in order to avoid giving information to the attacker. For example, if an attempt to login received a BLOCK verdict, the application can display a standard "Username or password is incorrect" message, rather than telling the user they are blocked by Device Fingerprinting.

Your application can prompt the user for multi-factor authentication (MFA) or some other check like CAPTCHA when a request receives a BLOCK or CHALLENGE verdict.

For example, in the DFP Example App, a CHALLENGE verdict requires the user to complete an MFA challenge even if they had previously logged in with the same device and marked it as "trusted".

Another common pattern is to block logins and send an "unusual activity" email. The user will not be able to log in until they have confirmed access to their email, which means attackers will not be able to directly gain access by phishing or credential-stuffing your application.

Shadow-banning is the practice of blocking an action while giving the appearance that the action succeeded. This is a form of opaque error that leads the attacker to waste their time and effort trying to continue.

For example, in the DFP Example App, a BLOCK verdict results in the application displaying an "Email magic link sent!" page even though no email was actually sent. An attacker might wait for an email, thinking that they have successfully breached the account.

In raffles, giveaways, and other similar contests, shadow-banning can be used to quietly prevent an attacker from winning real prizes. Because the attacker believes they entered successfully, they will not escalate their attack; but the shadow-ban prevents them from ever winning.

In longer-term fraud prevention strategies, your application may allow the action and log the fingerprints and verdict for later use.

For example, if you have your own "risk engine" that accumulates evidence of suspicious activity, BLOCK verdicts should increment the risk score. Once the risk score reaches your preferred threshold, you can take action.

Or in a consumer application, you may want to observe until you can ban a whole set of fraudulent accounts simultaneously. This is common in gaming and social applications, where attackers may create cheating rings or sockpuppet accounts that support each other. Eliminating the entire set of accounts at once can be more effective than picking off individual accounts one-at-a-time, which gives the attacker instant feedback to improve their deception.

For other enforcement logic options, reach out to support@stytch.com or your account team. We are happy to learn about your scenario and business to help you implement meaningful and precise enforcement.

Device Fingerprinting is a powerful tool for stopping bad actors, and it is complementary to other tools, including WAFs.

You may see high-velocity attacks that overwhelm your servers. Even though Device Fingerprinting detects bot activity and returns BLOCK verdicts, it still takes compute resources to lookup the fingerprints and block the bots.

In this situation, blocking traffic at your WAF, firewall, or other network layer can protect your compute resources so that you can serve real users. The Device Fingerprinting logs should help you identify IP addresses associated with the attack.

Other security tooling may be helpful in your overall fraud prevention strategy. For example, you can combine the device-level data of Device Fingerprinting with content-level data from a spam detection tool, or push your Device Fingerprinting logs to your security information and event management (SIEM) tool to correlate with other events.

For guidance on integrating with other tools, reach out to support@stytch.com or your account team.

Take a look at the DFP Example App. It's a simple implementation of using the Device Fingerprinting API to protect a login endpoint and enforce adaptive multi-factor authentication (MFA).