Hey,
We currently have our own UI for auth, so we’re looking to integrate with Stytch using just the backend SDK’s. I see in Stytch pricing page that there’s some security features, what do those look like when we have our own UI? I’m specifically thinking about the usual bot detection, brute force mitigation, breach detection, etc.
For example, I know in Clerk auth, we can add a captcha widget to our frontend that handles bot detection, and they also lock accounts based on attempts. Does Stytch offer anything similar?
I do see mention of device fingerprinting, and I have a related question there. It looks like we purchase a certain amount of fingerprinting. Say we buy 10k fingerprinting, what happens if we experience a bot attack and all 10k fingerprints are used up quickly? Do we lose protection at that point?
Thanks
Hey John!
what do those look like when we have our own UI? I’m specifically thinking about the usual bot detection, brute force mitigation, breach detection, etc.
These are all available regardless of whether you go with a frontend or backend Stytch integration! Going through them one by one:
- For bot detection, our DFP product does support fully backend integrations! We have an integration guide for implementing DFP in a backend context in our docs here. Happy to help answer any questions that might come up here as well.
- Outside of DFP, rate limits are the baseline mechanism for preventing brute force attacks, which are the same across frontend/backend Stytch integrations.
- Breach detection is configured at the Stytch Project level in the Passwords tab of your Stytch Dashboard, and similarly applies to both frontend and backend integrations.
in Clerk auth, we can add a captcha widget to our frontend that handles bot detection, and they also lock accounts based on attempts. Does Stytch offer anything similar?
For our frontend javascript SDKs we do have an off-the-shelf solution called DFP Protected Auth, which is built into our frontend SDKs.
A backend integration requires a few more steps in the guide linked above, but is still straightforward; essentially a script is loaded on your frontend to generate fingerprints, and then those fingerprints are looked up on your backend for decisioning.
Say we buy 10k fingerprinting, what happens if we experience a bot attack and all 10k fingerprints are used up quickly? Do we lose protection at that point?
You will not lose access or be hard blocked on fingerprinting! Our pay as you go plan comes with 10k fingerprints per month for free; after 10k fingerprints, the cost is $.005/fingerprint.
Hey Matt,
Thanks for the quick response with all the info! This makes sense to me and I’ll take a look.
I do have an additional question on the device fingerprinting feature. I realized I don’t actually have much context on what 10k device fingerprinting means, so I don’t know if 10k is a lot or very little and whether $0.005 per additional fingerprint is a good deal.
Can you provide some context and real world scenarios around what 10k fingerprints looks like? Is it that every request that comes in would be considered a fingerprint? If the same person does multiple auth requests, would they consume just one fingerprint or multiple?
Also, I think I personally just have a bit of hesitation when it comes to quota based security-type features since I’ve run into issues in the past with malicious actors running up our bill or exhausting our quota during an attack. If you could give some thoughts on how Stytch handles these cases or why this won’t be a problem, I’d appreciate it!
I realized I don’t actually have much context on what 10k device fingerprinting means, so I don’t know if 10k is a lot or very little and whether $0.005 per additional fingerprint is a good deal.
A fingerprint will be generated each time you want to inspect a particular request/device to decision on it, or otherwise perform traffic shaping.
For most applications, this happens during each login flow to determine if login attempt is a bot / programmatic traffic, though some applications do perform in-app fingerprinting on sensitive actions or on some regular cadence.
For the typical use case of fingerprinting on every login, one way to approximate the number of logins per month that will require fingerprinting is
(number of MAUs) * (average number of logins per user per month)
Also, I think I personally just have a bit of hesitation when it comes to quota based security-type features since I’ve run into issues in the past with malicious actors running up our bill or exhausting our quota during an attack. If you could give some thoughts on how Stytch handles these cases or why this won’t be a problem, I’d appreciate it!
Totally valid concern! A few things I’ll note here:
- A bad actor successfully frauding an application is (generally) more expensive that the cost to prevent that fraud.
- Often once you’ve identified a bad actor, you can stop them upstream, for example with temporary bans at the network or WAF level. This also helps conserve your own compute resources as well (to avoid spending them on a bad actor).
- Finally, though we cannot make any guarantee, we have, on a case by case basis, worked with customers if an attack happens that significantly impacts cost.