session-history/ohm/0026/SESSION-0026.1-TRANSCRIPT-2026-05-28T13-46--2026-05-28T13-50.md

# SESSION-0026.1 — AuthN/AuthZ security audit subsession (rfc-app v0.24.0)

Parent: SESSION-0026.0-TRANSCRIPT-2026-05-28T13-46--INPROGRESS.md
Date: 2026-05-28T13-46 → 2026-05-28T13-50 (America/Los_Angeles)
Role: subsession 0026.1 of OHM security-audit driver session 0026.
Mode: READ-ONLY. No edits, no deploys, no mutations. Only file written is this transcript.

## Goal

Audit the authentication / authorization surface of the rfc-app codebase
(`/Users/benstull/git/rfc-app`, tag v0.24.0): the email/OTC login flow,
passcodes, device-trust, Gitea OAuth + core auth, session/cookie security,
the admin role model, and per-endpoint authz guards across every
`api*.py` write/admin/owner endpoint. Verify deployment guarantee #4
("anonymous users are off-limits for any write/mutation"). Hunt for missing
guards, IDOR, and OTC/passcode brute-force/replay.

## Outcome

One High finding (OTC verify has no attempt limit / lockout — asymmetric
with the passcode path which does). Two Low/Info findings (session cookie
`https_only=False`; email-bounce webhook unauthenticated when env unset —
both documented dev contracts). Every enumerated write/admin/owner endpoint
enforces auth; no missing guards, no IDOR found. Admin role model is sound.

## Pre-state (what I found at the start)

- `auth.py` defines the dependency ladder: `require_user` (401 if anon) →
  `require_contributor` (adds muted + permission_state='granted' gate) →
  `require_admin` (role in owner/admin). Plus per-RFC predicates
  (`can_contribute_to_rfc`, `can_discuss_rfc`, `can_invite_to_rfc`,
  `is_rfc_owner`). `current_user` re-reads role + permission_state from DB
  every request (so grants/revokes take effect next request — good).
- Credentials: OTC 6-digit codes (bcrypt at rest, 10-min TTL, 60s request
  cooldown, single live code per email); passcodes (bcrypt, 5-fail/15-min
  per-account lockout, denylist, 4–20 chars); device-trust (256-bit CSPRNG,
  bcrypt, 30-day, HttpOnly+Secure+SameSite=Lax cookie); invite tokens
  (256-bit CSPRNG, bcrypt, 7-day, single-use).

## Turn-by-turn arc

1. Read auth.py + config.py. Dependency ladder is clean. Noted SECRET_KEY
   is `_required` (good — no insecure default). OAuth provisioning sets
   owner role only via OWNER_GITEA_LOGIN match; OTC/invite users get
   gitea_login="" / gitea_id=0 coalesced.

2. Read otc.py + passcode.py side by side. **Caught the asymmetry**:
   `passcode.verify_passcode` has a per-account failed-attempts counter +
   15-min lockout; `otc.verify_code` has NOTHING — it walks the last 5
   rows, bcrypt-checks, and returns "wrong" with no counter, no lockout,
   no per-IP throttle. The 60s cooldown lives in `request_code`, not
   `verify_code`. This is the headline finding.

3. Read device_trust.py + email_otc.py. Device-trust is solid (constant-time
   bcrypt walk, no early-exit, token never logged, cookie flags correct,
   user-scoped revoke). email_otc always returns 202 / logs failures —
   no email enumeration via the request path.

4. Read main.py (middleware + all /auth endpoints). Confirmed:
   - SessionMiddleware uses `https_only=False` (line 150) — itsdangerous-
     signed cookie, HttpOnly by default, but Secure flag off. Dev parity
     comment present. Behind HTTPS+proxy in prod this is low-impact but
     worth flagging.
   - `/auth/otc/verify` has NO rate-limit dependency, confirming finding #1
     at the endpoint layer too.
   - Turnstile gates `/auth/otc/request` ONLY, not verify.

5. Refutation pass on finding #1: Is there a global limiter? Grepped for
   RateLimit/slowapi/limiter/429 across backend/app — only tag_suggest.py
   (per-user, in-memory) and the OTC *request* cooldown 429. No global
   middleware, no limiter on verify. SPEC §ahead-of (line ~4100) discusses
   per-IP throttle for the *passcode* verify (which already has a per-
   account lockout) but never notes the OTC verify has no per-account limit
   at all. Quantified: single live code per email, bcrypt ~tens of ms,
   10^6 keyspace, 10-min TTL. Full sweep not possible in one TTL, but
   attacker re-requests (60s cooldown) to keep a live code and runs
   parallel verifies; expected ~500k guesses. bcrypt cost + TTL + single-
   live-code = real friction but NO attempt cap. Downgraded Critical→High.

6. Read api_admin.py end to end. Every endpoint calls require_admin; the
   user-search typeahead intentionally uses require_user (no privileged
   data). Role escalation well-guarded: only owner grants/changes owner;
   self-downgrade, self-mute, self-permission-flip, self-invite all refused;
   admins/owners not write-mutable. No spoof/escalation path. SOLID.

7. Enumerated routes+guards across api.py, api_prs.py, api_branches.py,
   api_graduation.py, api_invitations.py, api_notifications.py,
   api_discussion.py via grep. Every write/mutation route has require_user
   / require_contributor / require_admin, and the per-RFC write routes
   additionally call can_contribute_to_rfc / can_discuss_rfc /
   can_invite_to_rfc. GET read routes use current_user (nullable) — anon
   read is by design (guarantee #4 is about writes).

8. IDOR hunt — checked every owner/id-comparing helper:
   - api_prs `_can_merge`/`_can_withdraw`/`_can_edit_pr_text`: compare
     viewer.gitea_login against RFC frontmatter owners/arbiters cache and
     pr_row["opened_by"] — server-side data, not user-supplied. Safe.
   - api_branches `_require_branch_owner`/`_can_contribute`/
     `_can_read_branch`: branch grants keyed on grantee_user_id (session
     id), creator compared to gitea_login. Safe.
   - notification mute (`/api/users/{user_id}/notification-mute`): SQL
     scoped to viewer.user_id; only the {user_id} *target* is user-supplied
     and it's just the mute subject, not an ownership pivot. Self-mute
     refused. Safe.
   - invitations accept: requires auth + case-insensitive email match +
     refuses empty email; collaborator row keyed on viewer.user_id. Safe.
   - Considered: OTC/invite users have gitea_login="". Could "" match an
     owners list? Only if frontmatter literally contained "" — impossible
     from gitea_login frontmatter. `"" in []` is False. Killed as non-issue.

9. Checked anonymous-reachable mutation surfaces:
   - `/api/email/unsubscribe` (GET+POST): itsdangerous URLSafeSerializer
     signed token (SECRET_KEY, salted) → user_id+category not forgeable;
     idempotent, low-stakes; no expiry but URLSafeSerializer is fine here.
   - `/api/webhooks/email-bounce`: optional X-Webhook-Secret (constant-time
     compare) when WEBHOOK_EMAIL_BOUNCE_SECRET set; UNAUTHENTICATED when
     unset (documented v1 dev contract). Impact: flip email opt-out flags +
     mark outbound rows bounced. Low.
   - `/api/webhooks/...` Gitea receiver: mandatory HMAC-SHA256, constant-
     time compare, refuses to start without secret unless
     RFC_APP_INSECURE_WEBHOOKS=1. SOLID.
   - `/api/invites/claim`, `/auth/device-trust/start`: anon by design (they
     establish the session); both gated by 256-bit bcrypt-hashed tokens.

10. Confirmed db is a single shared sqlite connection (check_same_thread=
    False, isolation_level=None) — no incidental concurrency limiter that
    would mitigate the OTC brute-force.

## Cut state (final findings)

### High
- **F1 — OTC verify has no attempt limit / lockout / per-IP throttle.**
  `backend/app/otc.py:211 verify_code` (endpoint `backend/app/main.py:279
  /auth/otc/verify`). The passcode path (`passcode.py:262`) has a 5-fail/
  15-min per-account lockout; the OTC path has none. 60s cooldown is on
  *request* only. 6-digit code (10^6), 10-min TTL, single live code per
  email. Remediation: add a per-account failed-OTC-attempt counter +
  lockout mirroring passcode.py, and/or a per-IP 429 throttle on verify;
  consider invalidating the live code after N failures. Confidence: HIGH
  the control is absent (verified across module + endpoint + global grep).
  Severity argued down from Critical to High because bcrypt cost + 10-min
  TTL + single-live-code give real friction; still a genuine gap and an
  inconsistency with the passcode path.

### Low / Info
- **F2 — Session cookie `https_only=False`.** `backend/app/main.py:150`
  SessionMiddleware. Cookie is itsdangerous-signed + HttpOnly, but Secure
  is off "for dev parity." The device-trust cookie correctly sets
  Secure=True. In prod behind HTTPS the session cookie should also be
  Secure. Remediation: drive https_only from an env flag, true in prod.
  Confidence: HIGH it's set false; impact Low given HTTPS + signed cookie.
- **F3 — Email-bounce webhook unauthenticated when env unset.**
  `backend/app/api_notifications.py:543`. Documented v1 dev contract;
  impact limited to email opt-out flag flips + outbound-row status. Info/
  Low. Confidence HIGH on behavior, low on impact.

### What's solid (controls correctly implemented)
- Three-tier dependency ladder; `current_user` re-reads role +
  permission_state from DB every request (revokes take effect immediately).
- Admin role model: owner-only owner grants, self-downgrade/self-mute/
  self-permission/self-invite refusals, admins/owners not write-mutable.
  No escalation/spoof path. Every /api/admin/* endpoint require_admin.
- Every write/mutation endpoint across all api*.py files enforces auth;
  per-RFC writes additionally enforce can_*_to_rfc. No missing guard.
- No IDOR: owner/permission checks compare against server-side frontmatter
  cache / session user_id / pr opened_by, never a trusted user-supplied id.
- Passcode lockout (5/15min), denylist; OTC single-live-code + consume-
  before-provision (no replay, no double-sign-in).
- All tokens (OTC, passcode, device-trust, invite) bcrypt-hashed at rest;
  device-trust/invite tokens 256-bit CSPRNG; constant-time bcrypt walks,
  no early-exit timing leak; raw tokens never logged.
- Gitea webhook mandatory HMAC-SHA256 + constant-time compare; OAuth state
  param checked with secrets.compare_digest.
- SECRET_KEY is _required (no insecure default); unsubscribe tokens signed
  with it (salted, not forgeable).
- OTC request returns 202 regardless (no email enumeration); verify
  collapses wrong/unknown to one 400 (no enumeration); passcode verify
  collapses wrong/unknown likewise.

## What the driver needs to know

- F1 is the only finding worth a remediation slice. It is a real,
  exploitable-with-effort gap AND an internal inconsistency (passcode has a
  lockout, OTC doesn't). Recommend the driver fold it in at High; if the
  driver judges the bcrypt+TTL friction insufficient given OHM is publicly
  reachable, it could argue back toward Critical — I left it at High after
  refutation.
- F2/F3 are documented dev contracts; flag them but they are low priority.
  Worth a one-line confirmation that OHM's prod overlay sets
  WEBHOOK_EMAIL_BOUNCE_SECRET and serves over HTTPS (the device-trust
  cookie is Secure-only, so if OHM weren't HTTPS, device trust would
  already be broken — implying HTTPS is in fact present, which de-risks F2).
- The authz guard coverage is genuinely complete — guarantee #4 holds for
  every write/admin/owner endpoint I enumerated. No anon-write hole found.

## §19.2 candidates surfaced

- Per-account OTC-verify lockout + per-IP verify throttle (pairs with the
  SPEC's already-listed per-IP passcode-verify candidate). This is the
  remediation for F1 and is a flotilla-irrelevant, rfc-app-core change.