Skip to content

The v1 docs follow nauthera-server's main branch and its 0.x releases on the way to 1.0, so fields and APIs can still change.

v1

NautheraSignInFailureSpike

Docs version v1 (main)Nauthera is pre-1.0, in a design-partner program

Most password sign-ins are failing, at a rate that suggests an attack.

Meaning

Over 15 minutes, more than the threshold (60%) of password sign-in attempts in nauthera_auth_logins_total ended in something other than success, and failures ran above minRate (0.5 a second), for fifteen minutes. The failing results are invalid (wrong email or password), throttled (a throttle tripped, every verification slot was busy, or a locked account while auth.brute_force.reveal_lockout is off), locked and unavailable (the right password for a suspended or blocked account). Credential stuffing and password spraying look like this; so does an overloaded replica refusing sign-ins as throttled.

Impact

Security: someone may be testing stolen or guessed passwords, and some may succeed. End users: accounts under attack get locked (see NautheraAccountLockoutSpike), and sign-ins from a shared address may be throttled or asked for a captcha. Relying parties see their users fail to sign in.

Diagnosis

  1. What kind of failure: sum by (result) (rate(nauthera_auth_logins_total\{ job="<name>"\}[15m])). Mostly invalid is guessing; mostly throttled with high latency can be load (see NautheraServerHighLatency).
  2. In the admin dashboard, Threats (/admin/orgs/<slug>/threats): Sign-in attack shape names the pattern (credential cracking, password spraying, credential stuffing) and Behind the refused sign-ins ranks the addresses and accounts.
  3. The records: the Audit log page, or GET /v1/admin/orgs/&lt;slug&gt;/audit-events? action=auth.sign_in.completed&outcome=failure,denied with an admin token. Look at client IP, network zone and client_kind.
  4. Did any targeted account then sign in? Filter the same action with outcome=success for the accounts the ranking names.

Mitigation

  • Block or rate-limit the ranked source addresses or networks at the ingress or WAF.
  • Make the captcha appear sooner: lower config.auth.captcha.sign_in_after (3); keep auth.captcha.provider on (altcha needs no third party).
  • Tighten config.auth.brute_force.ip_max_attempts / ip_window if one address sends many attempts. Behind a proxy, check security.trusted_proxies first, or every client shares one address (see the client address).
  • Accounts that signed in during the attack from a ranked address: end their sessions and require a password change from their user page in the dashboard.

Escalation

Tell the security team while the attack is running, with the ranked addresses and the pattern the dashboard names. Escalate at once if successful sign-ins from attacking addresses appear. If you believe the server itself has a weakness, follow the responsible-disclosure process in Hardening rather than a public issue.

Alert runbooks · Generated from internal/runbook/alerts.yaml and operator/internal/runbook/alerts.yaml in nauthera-server.