# NautheraSignInFailureSpike

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](https://www.nauthera.io/docs/v1/configuration#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](https://www.nauthera.io/docs/v1/security#reporting-a-vulnerability)
rather than a public issue.

---

[Alert runbooks](https://www.nauthera.io/docs/v1/runbooks/alerts) · Generated from [`internal/runbook/alerts.yaml`](https://github.com/nauthera/nauthera-server/blob/main/internal/runbook/alerts.yaml) and [`operator/internal/runbook/alerts.yaml`](https://github.com/nauthera/nauthera-server/blob/main/operator/internal/runbook/alerts.yaml) in nauthera-server.