Use case
Credential stuffing protection that knows which logins failed
Credential stuffers replay leaked email and password pairs against your login. Each request looks like a customer who mistyped. camada sees the pattern because your app tells it which logins failed, for which account, as a hash.
The pattern
What it looks like in your traffic
- Many login POSTs from one client and almost no page views.
- Failed logins spread across many of your accounts, one or two tries each: a password spray.
- Logins from hosting and cloud networks, where your customers rarely sit.
- The same client build spread over many IPs, each one staying under a per-IP limit.
Detection
How camada scores it
| What camada looks for | Score |
|---|---|
| Failed logins on 10+ of your accounts, at most 2 tries each (password spray, from track()) | +50 |
| 20+ failed logins across 3+ accounts (from track()) | +40 |
| 10+ login POSTs, over 80% POSTs, at most one page view | +35 |
| 10+ POSTs answered 401 or 403 | +35 |
| A hosting or cloud network on a login, signup or checkout path | +30 |
| One client build failing logins from 10+ IPs, each under the per-IP bar | +50, +65 at 20+ IPs |
| Flagged malicious by 3 or more other paying organizations in the last 7 days | +40 |
At the default sensitivity, a client at 60 goes to the investigation agent, which reads its requests and writes a verdict with evidence. A block needs a malicious verdict at 80% confidence or more.
A sample of the rules, with their default weights. The full pipeline and more rules are on how it works.
Setup
Set it up
- Install the SDK for your framework. Framework quickstarts →
- Call track() with login_failed and login_succeeded where your sign-in code knows the outcome. The account id is HMAC-hashed in your process. track() in the Express quickstart →
- Turn on challenge for suspect browsers if you would rather ask than block. How a challenge works →
Limits
What camada does not do
- camada judges clients every few minutes, not on each request. The first tries from a new client reach your login until a run flags it and your app pulls the new blocklist.
- Without track(), camada only sees status codes and paths. Rules that count failed logins per account need it.
- camada does not check passwords against breach lists and does not replace rate limits or MFA on your login.
Questions
Common questions
How is credential stuffing different from brute force?
Brute force tries many passwords on one account. Credential stuffing tries leaked email and password pairs, usually one or two per account, across many accounts. Per-account lockouts rarely trip, which is why camada counts failures across accounts and across IPs.
Does camada see my users' passwords or emails?
No. Request and response bodies never leave your app. track() sends an event name and an HMAC of the identifier you pass, computed in your process.
Will a customer who forgot their password get blocked?
A few failed logins from one person do not reach the thresholds above. Rules that count a real person's signs, like input events in the browser beacon, lower the score. New projects start in a learning window that only recommends, so you see what would be blocked first.
Other attacks camada handles: Scraping · AI agent abuse · CVE exploit scans. Plans and the 14-day trial: pricing.