Attack protection

Attackers don't need a bug in your app. A stolen password list, a script that guesses, or a disposable inbox is enough. These policies run on the environment, on the hosted sign-in path, before a session is issued.

Open the console, select the environment, then Authentication > Policies. Save each card on its own. Detections also show up as Lidar Signals, so a block and an investigation share the same trail.

Brute force

Brute force limits consecutive failed sign-ins. Enable brute-force protection is on by default: 5 failures, then a 15-minute lockout, with Progressive delay adding wait time after each miss.

Raise Max failures before lockout if real users mistype on a shared kiosk. Shorten Lockout duration only after you can see the failures in Lidar. A lockout that never expires turns a guess into a denial of service against the real user.

Breached passwords

Breached passwords compares the password with known breach corpora using k-anonymity. Authdog does not send the raw password to the corpus.

By default the check runs On sign-up and On password change, and When a match is found is Hard block. Warn only records the hit and still accepts the password. Use warn while you measure how many real users would be rejected, then switch back to hard block.

The password policy on the Password card (minimum length, character classes) is a separate rule. A long password can still be breached. Keep both.

Bots

Two layers, and they stack:

• Bot detection on this Policies tab scores sign-in and sign-up. Sensitivity runs from Low, fewer challenges to High, aggressive. Challenge mode is Silent score only, Step-up challenge, or Block. Enforcement uses Cloudflare bot scores when they are present. Lidar bot scoring still runs if you also enable a CAPTCHA.
• Bot protection under Authentication > Add-ons is the hosted-page challenge: Google reCAPTCHA or Cloudflare Turnstile. Put an invisible challenge on signup, waitlist, and password_reset first. Those are the flows a script hits before it ever tries a password.

Don't enable both CAPTCHA providers for the same action unless you intend reCAPTCHA to take over.

Device risk

Device risk covers two cases:

• Challenge unrecognized devices asks for step-up when the sign-in fingerprint is new. This is the control for a stolen password used from a machine the user has never used.
• Impossible travel compares successive sign-in locations with realistic travel time. Normal flags the session for Lidar. Strict challenges when a CAPTCHA is configured. Off skips the check.

Strict mode without a CAPTCHA cannot present the challenge it wants. Configure bot protection first if you select Strict.

Account enumeration

A sign-up form that says "this email is taken" tells an attacker which accounts exist. On Users > Settings, turn on Prevent account enumeration. The form no longer reveals whether the address is registered.

Rate limiting

Rate limiting throttles selected endpoints for the environment. Set Window (seconds) and Max attempts, then Scope (IP address, IP + user, or User). Apply it to sign-in (including magic link and SMS or WhatsApp codes), sign-up, password reset, or any combination.

When exceeded is Challenge (soft) or Deny (hard block). Start with challenge on sign-in so a corporate NAT doesn't lock out a whole office. Use deny on password reset, where a burst is almost never a real user.

What to turn on first

1. Leave brute force and breached-password hard block at their defaults.
2. Add an invisible CAPTCHA on sign-up, waitlist, and password reset.
3. Turn on Prevent account enumeration before you launch a public sign-up form.
4. Watch Lidar Signals for a day before you raise bot sensitivity to High.

Related