Concern: Ory Kratos Recovery Flow Might Be Vulnerable to Brute-Force Guessing

We are using Ory Kratos (self-hosted) for authentication in our product, and I am looking for advice on how to harden the account recovery flow.

Recently, an external actor claimed that our current recovery setup could be abused to brute-force recovery codes. We are still investigating, but I wanted to check with the community to understand what the best practices are, especially since we are following Kratos' recommendation to use recovery codes over links for security and UX reasons.

Our Setup

We are using the code-based recovery flow (not recovery links), as recommended in the Kratos documentation.

Here is how it currently works:

1. GET /recovery/browser – Creates a recovery flow, returning a flow ID and CSRF token.
2. POST /recovery (email) – User submits their email, and Kratos sends a 6-digit code.
3. POST /recovery (code) – User submits the code to verify and log in or reset their password.

Current configuration

What Was Claimed

The reporter claimed that because each recovery flow generates its own random code and previous flows remain valid, it is possible to:

• Create many recovery flows for the same user
• Each flow allows up to 5 guesses
• All flows stay valid for 3 hours
• Use multiple IPs to bypass the per-IP rate limit

This effectively multiplies the total number of valid guesses by the number of concurrent flows, making a large-scale brute-force attack theoretically possible.

The Math

Each code has a 1-in-1,000,000 chance of being guessed correctly.

If an attacker makes (T) total guesses across all flows:

P(success) = 1 - (1 - 10^-6)^T

With distributed IPs, the attacker could reach millions of guesses quickly.
For example, with 1,000 IPs, they could reach 3M total guesses in roughly 10 hours under our current rate limits.

What I Would Like Community Input On

1. Invalidating old flows

   • Is there a way (built-in or via hooks) to expire older recovery flows when a new one is created for the same user?
   • Or should this be handled at the proxy or application layer?

2. Rate limiting improvements

   • What is the best way to implement per-identity or per-email throttling?
   • Has anyone combined Kratos' built-in limits with reverse proxy or API gateway limits effectively?

3. Code vs. link recovery

   • The Kratos docs recommend using codes over links. Does that recommendation still hold for setups like this?
   • Would longer alphanumeric tokens or shorter validity windows make sense here?

4. Additional safeguards

   • Has anyone successfully added CAPTCHA (hCaptcha or reCAPTCHA) to recovery flows?
   • What about implementing temporary account lockouts or exponential backoff after repeated recovery attempts?

5. Production hardening

   • For teams running Kratos in production, how are you protecting your recovery endpoints against DDoS or brute-force abuse?
   • Any shared patterns, configurations, or lessons learned would be greatly appreciated.

TL;DR

• Using Kratos' recommended code-based recovery flow
• 6-digit code valid for 3 hours
• 5 attempts per flow
• Unlimited concurrent flows per user
• IP-only rate limiting
• External actor claims this setup can be brute-forced using distributed recovery flows
• Threat of Email delivery abuse, performance impact
• Looking for community guidance on mitigation strategies, configuration best practices, and patterns for flow invalidation

I would really appreciate any insights or experiences others can share.