@openparachute/hub 0.7.3-rc.3 → 0.7.3-rc.5

package/src/invites.ts

@@ -37,10 +37,23 @@
  * v13): the redemption form shows it read-only and the redeem handler
  * enforces it. NULL = redeemer picks their own.
  *
- * Single-use is enforced by stamping `used_at` on redemption — a replay
- * attempt sees the row with `used_at` set and `redeemInvite` throws
- * `InviteUsedError`. Revocation is a separate `revoked_at` stamp the admin
- * sets before redemption. Expiry is enforced at redeem-time.
+ * MULTI-USE (migration v15, DEMO-PREP-2026-06-25 Workstream B): an invite
+ * carries `max_uses` (how many accounts ONE link may create) + `used_count`
+ * (how many it has). A redeem is refused once `used_count >= max_uses`. A
+ * LEGACY single-use invite is exactly `max_uses = 1` (the column default), so
+ * pre-v15 invites and default-shaped new ones behave identically to before.
+ * `used_at` is RETAINED — stamped on the FIRST redeem — so the admin list's
+ * "redeemed" status and any single-use lookups keep reading the same signal.
+ * Exhaustion is enforced atomically in `recordInviteRedemption` (the
+ * `used_count < max_uses` guard in the UPDATE), so two concurrent redeems of
+ * the last remaining seat can't both succeed.
+ *
+ * Revocation is a separate `revoked_at` stamp the admin sets before
+ * redemption (terminal regardless of remaining uses). Expiry is enforced at
+ * redeem-time. A public-signup link also captures the redeemer's `email`
+ * (B2 — the contactable identity, also stored per-account on `users.email`)
+ * and may carry a `vault_cap_bytes` to stamp onto each provisioned vault (B4
+ * — persisted to `vault_caps` for the Phase-2 enforcement PR to read).
  */
 import type { Database } from "bun:sqlite";
 import { createHash, randomBytes } from "node:crypto";
@@ -70,6 +83,24 @@ export interface Invite {
   provisionVault: boolean;
   /** `'internal' | 'off'` mirror knob for the provisioned vault, or null. */
   defaultMirror: string | null;
+  /**
+   * How many accounts this link may create (v15). 1 = legacy single-use
+   * (the column default); >1 = a multi-use public-signup link.
+   */
+  maxUses: number;
+  /** How many accounts this link HAS created (v15). Redeem refused once == maxUses. */
+  usedCount: number;
+  /**
+   * Most-recent redeemer's email (v15, B2), or null. For a multi-use link
+   * the canonical per-account email lives on `users.email`; this column
+   * holds the latest redeemer's for the admin's at-a-glance audit.
+   */
+  email: string | null;
+  /**
+   * Per-vault storage cap (bytes) to stamp onto each provisioned vault
+   * (v15, B4), or null to provision uncapped (legacy behavior).
+   */
+  vaultCapBytes: number | null;
   expiresAt: string;
   usedAt: string | null;
   redeemedUserId: string | null;
@@ -98,6 +129,20 @@ export class InviteUsedError extends Error {
   }
 }
 
+/**
+ * A multi-use link whose seats are all taken (`used_count >= max_uses`). For
+ * a single-use (max_uses=1) link this is the same condition the legacy
+ * `InviteUsedError` named, but the redeem path throws `InviteUsedError` for a
+ * single-use link (familiar "already used" copy) and `InviteExhaustedError`
+ * for a multi-use one ("all signups taken") so the message can differ.
+ */
+export class InviteExhaustedError extends Error {
+  constructor() {
+    super("invite has reached its maximum number of signups");
+    this.name = "InviteExhaustedError";
+  }
+}
+
 export class InviteRevokedError extends Error {
   constructor() {
     super("invite has been revoked");
@@ -113,6 +158,10 @@ interface Row {
   role: string;
   provision_vault: number;
   default_mirror: string | null;
+  max_uses: number;
+  used_count: number;
+  email: string | null;
+  vault_cap_bytes: number | null;
   expires_at: string;
   used_at: string | null;
   redeemed_user_id: string | null;
@@ -129,6 +178,10 @@ function rowToInvite(r: Row): Invite {
     role: r.role,
     provisionVault: r.provision_vault === 1,
     defaultMirror: r.default_mirror,
+    maxUses: r.max_uses,
+    usedCount: r.used_count,
+    email: r.email,
+    vaultCapBytes: r.vault_cap_bytes,
     expiresAt: r.expires_at,
     usedAt: r.used_at,
     redeemedUserId: r.redeemed_user_id,
@@ -142,10 +195,19 @@ export function hashInviteToken(rawToken: string): string {
   return createHash("sha256").update(rawToken).digest("hex");
 }
 
-/** Derive an invite's status from its stamps + the current time. */
+/**
+ * Derive an invite's status from its stamps + the current time.
+ *
+ * Multi-use (v15): an invite is "redeemed" only once every seat is taken
+ * (`usedCount >= maxUses`). A partially-used multi-use link (some seats left,
+ * not expired/revoked) is still "pending" — it can take more signups. A
+ * legacy single-use link (maxUses=1) flips to "redeemed" on its first
+ * redeem, exactly as before, because 1 >= 1. Expired wins over a not-yet-
+ * exhausted link; revoked + exhausted are checked first (terminal).
+ */
 export function inviteStatus(invite: Invite, now: Date = new Date()): InviteStatus {
   if (invite.revokedAt) return "revoked";
-  if (invite.usedAt) return "redeemed";
+  if (invite.usedCount >= invite.maxUses) return "redeemed";
   if (now.getTime() > new Date(invite.expiresAt).getTime()) return "expired";
   return "pending";
 }
@@ -166,6 +228,16 @@ export interface IssueInviteOpts {
   provisionVault?: boolean;
   /** `'internal' | 'off'` mirror knob for the provisioned vault. */
   defaultMirror?: string | null;
+  /**
+   * How many accounts this link may create (v15). Default 1 (single-use,
+   * the legacy shape). Caller validates the upper bound.
+   */
+  maxUses?: number;
+  /**
+   * Per-vault storage cap (bytes) to stamp onto each provisioned vault
+   * (v15, B4). Omit/null = provision uncapped (legacy behavior).
+   */
+  vaultCapBytes?: number | null;
   /** Lifetime in seconds. Default {@link DEFAULT_INVITE_TTL_SECONDS} (7 days). */
   expiresInSeconds?: number;
   now?: () => Date;
@@ -198,12 +270,15 @@ export function issueInvite(db: Database, opts: IssueInviteOpts): IssuedInvite {
   const username = opts.username ?? null;
   const provisionVault = opts.provisionVault ?? true;
   const defaultMirror = opts.defaultMirror ?? null;
+  const maxUses = opts.maxUses ?? 1;
+  const vaultCapBytes = opts.vaultCapBytes ?? null;
 
   db.prepare(
     `INSERT INTO invites
        (token, created_by, vault_name, username, role, provision_vault, default_mirror,
+        max_uses, used_count, email, vault_cap_bytes,
         expires_at, used_at, redeemed_user_id, revoked_at, created_at)
-     VALUES (?, ?, ?, ?, ?, ?, ?, ?, NULL, NULL, NULL, ?)`,
+     VALUES (?, ?, ?, ?, ?, ?, ?, ?, 0, NULL, ?, ?, NULL, NULL, NULL, ?)`,
   ).run(
     tokenHash,
     opts.createdBy,
@@ -212,6 +287,8 @@ export function issueInvite(db: Database, opts: IssueInviteOpts): IssuedInvite {
     role,
     provisionVault ? 1 : 0,
     defaultMirror,
+    maxUses,
+    vaultCapBytes,
     expiresAt,
     createdAt,
   );
@@ -226,6 +303,10 @@ export function issueInvite(db: Database, opts: IssueInviteOpts): IssuedInvite {
       role,
       provisionVault,
       defaultMirror,
+      maxUses,
+      usedCount: 0,
+      email: null,
+      vaultCapBytes,
       expiresAt,
       usedAt: null,
       redeemedUserId: null,
@@ -275,7 +356,7 @@ export function usernameReservedByPendingInvite(
   const row = db
     .query<{ token: string }, [string, string]>(
       `SELECT token FROM invites
-       WHERE username = ? AND used_at IS NULL AND revoked_at IS NULL AND expires_at > ?
+       WHERE username = ? AND used_count < max_uses AND revoked_at IS NULL AND expires_at > ?
        LIMIT 1`,
     )
     .get(username, now.toISOString());
@@ -295,11 +376,13 @@ export function listInvites(
 }
 
 /**
- * Validate an invite for redemption WITHOUT consuming it. Throws on every
- * not-redeemable branch (not-found / expired / used / revoked). Returns the
- * invite when it's redeemable. The redemption handler calls this FIRST (so a
- * bad token is rejected before any account/vault work), then does
- * createUser, then `consumeInvite` AFTER the user row commits.
+ * Validate an invite for redemption WITHOUT recording one. Throws on every
+ * not-redeemable branch (not-found / expired / exhausted / revoked). Returns
+ * the invite when it's redeemable. The redemption handler calls this FIRST (so
+ * a bad token is rejected before any account/vault work), then does createUser,
+ * then `recordInviteRedemption` INSIDE the user-row transaction (the atomic
+ * seat-lock — the `< max_uses` UPDATE guard is what actually prevents an
+ * over-seat under concurrency; this early check is the fast-path rejection).
  */
 export function assertInviteRedeemable(
   db: Database,
@@ -308,10 +391,15 @@ export function assertInviteRedeemable(
 ): Invite {
   const invite = findInviteByRawToken(db, rawToken);
   if (!invite) throw new InviteNotFoundError();
-  // Revoked + used are terminal regardless of clock; check them before expiry
-  // so a revoked-then-expired invite reports the more specific reason.
+  // Revoked + exhausted are terminal regardless of clock; check them before
+  // expiry so a revoked-then-expired invite reports the more specific reason.
   if (invite.revokedAt) throw new InviteRevokedError();
-  if (invite.usedAt) throw new InviteUsedError();
+  // Exhaustion (v15): seats all taken. A single-use link (maxUses=1) throws
+  // the familiar InviteUsedError ("already used"); a multi-use one throws
+  // InviteExhaustedError ("all signups taken") so the copy can differ.
+  if (invite.usedCount >= invite.maxUses) {
+    throw invite.maxUses > 1 ? new InviteExhaustedError() : new InviteUsedError();
+  }
   if (now.getTime() > new Date(invite.expiresAt).getTime()) {
     throw new InviteExpiredError();
   }
@@ -319,39 +407,75 @@ export function assertInviteRedeemable(
 }
 
 /**
- * Mark an invite consumed — stamp `used_at` + `redeemed_user_id`. Called
- * Called within the account-creation transaction (or after a committed user
- * row). Single-use + not-revoked is enforced by the
- * `used_at IS NULL AND revoked_at IS NULL` guard in the UPDATE: a racing
- * second redeem — or a concurrent revoke — updates zero rows and the caller
- * treats that as already-consumed/revoked. Race-safe because sqlite
- * serializes writes.
+ * Record ONE redemption against an invite — the multi-use-aware consume
+ * (v15). Atomically:
+ *   - increments `used_count` by 1,
+ *   - stamps `used_at` on the FIRST redeem only (COALESCE keeps the original),
+ *   - records the redeemer's `email` (B2) + `redeemed_user_id` as the
+ *     MOST-RECENT redeemer (the canonical per-account email lives on
+ *     `users.email`; this is the admin's at-a-glance latest).
+ *
+ * Exhaustion + revocation are enforced by the `used_count < max_uses AND
+ * revoked_at IS NULL` guard in the UPDATE: a racing redeem that would take a
+ * seat past the cap — or one racing a revoke — updates zero rows, and the
+ * caller treats that as exhausted/revoked. Race-safe because sqlite
+ * serializes writes (a legacy single-use link is just the max_uses=1 case:
+ * the second concurrent redeem sees `used_count`=1, fails the `< max_uses`
+ * guard, and changes zero rows — exactly the old single-use behavior).
  *
- * Returns `true` if THIS call consumed the invite, `false` otherwise.
+ * Returns `true` if THIS call recorded a redemption, `false` otherwise.
  */
-export function consumeInvite(
+export function recordInviteRedemption(
   db: Database,
   tokenHash: string,
   redeemedUserId: string,
+  email: string | null = null,
   now: Date = new Date(),
 ): boolean {
+  const stamp = now.toISOString();
   const res = db
     .prepare(
-      "UPDATE invites SET used_at = ?, redeemed_user_id = ? WHERE token = ? AND used_at IS NULL AND revoked_at IS NULL",
+      `UPDATE invites
+       SET used_count = used_count + 1,
+           used_at = COALESCE(used_at, ?),
+           redeemed_user_id = ?,
+           email = ?
+       WHERE token = ? AND used_count < max_uses AND revoked_at IS NULL`,
     )
-    .run(now.toISOString(), redeemedUserId, tokenHash);
+    .run(stamp, redeemedUserId, email, tokenHash);
   return res.changes > 0;
 }
 
+/**
+ * Legacy single-use consume — thin wrapper over {@link recordInviteRedemption}
+ * for callers that don't capture email. Retained for backwards compatibility;
+ * the redeem path uses `recordInviteRedemption` directly so it can record the
+ * email. Race-safe + exhaustion-aware via the underlying function.
+ *
+ * Returns `true` if THIS call recorded a redemption, `false` otherwise.
+ */
+export function consumeInvite(
+  db: Database,
+  tokenHash: string,
+  redeemedUserId: string,
+  now: Date = new Date(),
+): boolean {
+  return recordInviteRedemption(db, tokenHash, redeemedUserId, null, now);
+}
+
 /**
  * Revoke a pending invite (admin DELETE). Stamps `revoked_at` only when the
- * invite isn't already used or revoked. Returns `true` if this call revoked
- * it, `false` if it was already consumed/revoked or not found.
+ * invite still has seats left (`used_count < max_uses`) and isn't already
+ * revoked. A multi-use link can be revoked mid-life to cut off its remaining
+ * seats; a fully-exhausted link is terminal and revoke is a no-op. (For a
+ * legacy single-use link `used_count < max_uses` is equivalent to the old
+ * `used_at IS NULL` guard.) Returns `true` if this call revoked it, `false`
+ * if it was already exhausted/revoked or not found.
  */
 export function revokeInvite(db: Database, tokenHash: string, now: Date = new Date()): boolean {
   const res = db
     .prepare(
-      "UPDATE invites SET revoked_at = ? WHERE token = ? AND used_at IS NULL AND revoked_at IS NULL",
+      "UPDATE invites SET revoked_at = ? WHERE token = ? AND used_count < max_uses AND revoked_at IS NULL",
     )
     .run(now.toISOString(), tokenHash);
   return res.changes > 0;
@@ -373,7 +497,7 @@ export function revokeInvitesForVault(
 ): number {
   const res = db
     .prepare(
-      "UPDATE invites SET revoked_at = ? WHERE vault_name = ? AND used_at IS NULL AND revoked_at IS NULL",
+      "UPDATE invites SET revoked_at = ? WHERE vault_name = ? AND used_count < max_uses AND revoked_at IS NULL",
     )
     .run(now.toISOString(), vaultName);
   return Number(res.changes);

package/src/oauth-handlers.ts

@@ -72,6 +72,12 @@ import {
 } from "./oauth-ui.ts";
 import { isSameOriginRequest } from "./origin-check.ts";
 import { buildPendingLoginCookie, createPendingLogin } from "./pending-login.ts";
+import {
+  authIpCeilingRateLimiter,
+  clientIpFromRequest,
+  compositeKey,
+  loginRateLimiter,
+} from "./rate-limit.ts";
 import { isHttpsRequest } from "./request-protocol.ts";
 import { narrowResourceVaultScopes, resolveResourceVault } from "./resource-binding.ts";
 import { isNonRequestableScope, isRequestableScope, scopeIsAdmin } from "./scope-explanations.ts";
@@ -1386,12 +1392,40 @@ async function handleLoginSubmit(
   db: Database,
   req: Request,
   form: Awaited<ReturnType<Request["formData"]>>,
-  _deps: OAuthDeps,
+  deps: OAuthDeps,
   csrfToken: string,
 ): Promise<Response> {
   const username = String(form.get("username") ?? "");
   const password = String(form.get("password") ?? "");
   const params = paramsFromForm(form);
+  // Rate-limit gate — AFTER CSRF (verified by the `handleAuthorizePost` caller)
+  // and BEFORE the credential check. This `/oauth/authorize` password door had
+  // NO rate-limit before; without it an attacker got an unbounded brute-force
+  // channel that bypassed `/login`'s floor entirely. Two tiers, reusing the
+  // SAME `loginRateLimiter` instance + the SAME `compositeKey(ip, username)`
+  // scheme as `/login`, so the two password doors share ONE per-account bucket
+  // (an attacker can't get 5 tries at `/login` PLUS another 5 here). The coarse
+  // per-IP CEILING backstops username-rotation; the per-(ip,username) FLOOR is
+  // the brute-force floor.
+  const clientIp = clientIpFromRequest(req);
+  const now = deps.now ? deps.now() : new Date();
+  const ceiling = authIpCeilingRateLimiter.checkAndRecord(clientIp, now);
+  const floor = loginRateLimiter.checkAndRecord(compositeKey(clientIp, username), now);
+  if (!ceiling.allowed || !floor.allowed) {
+    const retryAfterSeconds = Math.max(
+      ceiling.allowed ? 0 : (ceiling.retryAfterSeconds ?? 1),
+      floor.allowed ? 0 : (floor.retryAfterSeconds ?? 1),
+    );
+    return htmlResponse(
+      renderLogin({
+        params,
+        csrfToken,
+        errorMessage: `Too many login attempts. Try again in ${retryAfterSeconds} seconds.`,
+      }),
+      429,
+      { "retry-after": String(retryAfterSeconds) },
+    );
+  }
   if (!username || !password) {
     return htmlResponse(
       renderLogin({ params, csrfToken, errorMessage: "Username and password are required." }),

package/src/rate-limit.ts

@@ -1,17 +1,23 @@
 /**
  * Rate-limit primitives for hub auth-surface endpoints.
  *
- * Two limiters today (one floor each — neither is the primary defense):
+ * Each limiter is a floor, not the primary defense. Two are highlighted below
+ * for their contrasting threat models; the rest (`/login/2fa`, vault-token
+ * mint, public signup) are documented at their `export const` definitions.
+ * The public-signup limiter is the deliberate OUTLIER — generous, not tight —
+ * because its endpoint is meant to be redeemed by a room of people sharing one
+ * egress IP (see `SIGNUP_MAX_ATTEMPTS`).
  *
- *   - `/login` (per-IP, hub#187 / hub#188): 5 attempts / 15 min.
- *     Lands as a floor under brute-force after hub#187 collapsed the
- *     public-reach matrix: with a cloudflare tunnel up, `/login` is now
- *     reachable from the open internet, and 2FA (#186) is the next PR
- *     rather than this one. A 5-attempts-per-15-minute bucket per IP is
- *     the standard login-form floor; it's not the primary defense, just
- *     the one that turns "infinite credential grinding" into "rotate IPs".
- *     (Endpoint was `/admin/login` pre-rename; bucket logic is path-
- *     agnostic so the rename was a comment-only change here.)
+ *   - `/login` (per-account floor + per-IP ceiling): the FLOOR is keyed by
+ *     `compositeKey(ip, username)` at 5 attempts / 15 min, shared with the
+ *     `/oauth/authorize` password door so both doors feed ONE per-account
+ *     bucket; the CEILING is `authIpCeilingRateLimiter` at 60 / 15 min keyed
+ *     by IP alone. Re-keyed from pure per-IP so a room of users behind one
+ *     NAT'd egress IP (shared wifi / cloudflare tunnel) no longer pool into a
+ *     single 5-slot bucket — the per-account floor still turns "infinite
+ *     credential grinding" into "rotate IPs", while the IP ceiling backstops
+ *     username-rotation. (Endpoint was `/admin/login` pre-rename; bucket
+ *     logic is path-agnostic so the rename was a comment-only change here.)
  *
  *   - `/account/change-password` (per-user, hub#282): 3 attempts / 5 min.
  *     The endpoint is session-gated, so the threat model isn't open-
@@ -86,13 +92,27 @@ export const CHANGE_PASSWORD_MAX_ATTEMPTS = 3;
  * factor step (hub#473) sits behind a verified password + a short-lived
  * pending-login token, so the threat model is "attacker who already has the
  * password grinding 6-digit codes / backup codes." A 5-attempt / 15-min
- * bucket per IP turns 10^6-space TOTP grinding into "rotate IPs," same floor
- * as `/login`. Keyed by IP (the pending-login token is short-lived and an
- * attacker could mint many, so IP is the stable actor key here).
+ * floor turns 10^6-space TOTP grinding into "rotate IPs," same floor as
+ * `/login`. Keyed by `compositeKey(ip, userId)` (the shared-egress-IP fix) so
+ * each 2FA-enrolled user behind one NAT'd / Cloudflare egress IP gets their own
+ * floor — the STABLE userId from the pending-login, NOT the rotating pending
+ * token. The coarse per-IP `authIpCeilingRateLimiter` backstops it.
  */
 export const TOTP_WINDOW_MS = 15 * 60 * 1000;
 /** `/login/2fa` attempts allowed per window. 6th within the window is denied. */
 export const TOTP_MAX_ATTEMPTS = 5;
+/**
+ * Coarse per-IP CEILING shared by all interactive auth doors (`/login`, the
+ * `/oauth/authorize` password door, `/login/2fa`). 60 attempts / 15 min — the
+ * same generous cap as public signup (`SIGNUP_MAX_ATTEMPTS`), chosen so a
+ * ~20-person demo room behind ONE NAT'd / Cloudflare egress IP clears it
+ * comfortably. It exists ONLY as a backstop against username-rotation: the
+ * per-(ip,identity) FLOORs stay tight at 5/15min, but an attacker who rotates
+ * usernames against one IP would otherwise get a fresh 5-slot floor per name.
+ * This ceiling caps total per-IP auth volume regardless of identity. Reuses the
+ * 15-min `WINDOW_MS`.
+ */
+export const AUTH_IP_CEILING_MAX_ATTEMPTS = 60;
 /**
  * `POST /account/vault-token/<name>` window length: 10 minutes. The endpoint
  * is session-gated and assignment-capped (a friend can only mint
@@ -109,6 +129,27 @@ export const VAULT_TOKEN_MINT_WINDOW_MS = 10 * 60 * 1000;
  * minutes is generous for a human and still chokes a stolen-cookie flood.
  */
 export const VAULT_TOKEN_MINT_MAX_ATTEMPTS = 10;
+/**
+ * `POST /account/setup/<token>` (public invite redemption / signup) window
+ * length: 15 minutes — same window as `/login`, but a MUCH larger cap (below)
+ * because the threat model is the opposite. A public multi-use signup link is
+ * meant to be redeemed by a ROOM OF PEOPLE, and a demo room shares ONE NAT'd
+ * egress IP — so a per-IP `/login`-sized cap (5/15min) would 429 the ~6th
+ * legitimate signer. This bucket is deliberately generous so a shared egress
+ * IP comfortably handles a cohort, while still being a floor against an
+ * attacker scripting account creation against an open link (the invite's
+ * own `max_uses` + expiry are the primary bound; this is the abuse floor).
+ * Separate bucket from `/login` so a signup flurry never burns the login
+ * window, and vice-versa.
+ */
+export const SIGNUP_WINDOW_MS = 15 * 60 * 1000;
+/**
+ * `POST /account/setup/<token>` attempts allowed per IP per window. 60 is
+ * comfortably above a single demo room behind one NAT (and well above any
+ * legitimate human's retries) while still capping a scripted-abuse rate to
+ * ~4/min sustained. The 61st attempt within the window is denied.
+ */
+export const SIGNUP_MAX_ATTEMPTS = 60;
 /** Sentinel for the IP-extraction priority chain when nothing parsed. */
 export const UNKNOWN_IP_SENTINEL = "unknown";
 
@@ -209,9 +250,19 @@ export class RateLimiter {
 }
 
 /**
- * `/login` rate limiter — per-IP, 5 attempts / 15 min. Exported as a
- * singleton so all callers share one bucket map (rotating IPs across the
- * test suite or across a real attack must hit the same backing store).
+ * `/login` (+ the `/oauth/authorize` password door) rate limiter — per-
+ * account/per-half-login floor, keyed (ip,identity), 5 attempts / 15 min.
+ * RE-KEYED from per-IP to `compositeKey(ip, username)` (the shared-egress-IP
+ * fix): behind NAT / Cloudflare every user in a room presents one
+ * CF-Connecting-IP, so a per-IP-only key pooled the whole room into one 5-slot
+ * bucket and 429'd the 6th legitimate sign-in. Keyed by (ip,username) instead,
+ * each account gets its own floor while still pinning the floor to the IP so a
+ * single attacker can't grind one account from one box past 5 tries. BOTH
+ * password doors (`/login` and `/oauth/authorize` `__action=login`) share this
+ * ONE instance + the SAME key scheme, so an attacker can't get 5 tries per door
+ * against the same account. Exported as a singleton so all callers share one
+ * bucket map. The coarse per-IP `authIpCeilingRateLimiter` backstops
+ * username-rotation across this floor.
  */
 export const loginRateLimiter = new RateLimiter(MAX_ATTEMPTS, WINDOW_MS);
 
@@ -226,14 +277,30 @@ export const changePasswordRateLimiter = new RateLimiter(
 );
 
 /**
- * `/login/2fa` rate limiter — per-IP, 5 attempts / 15 min (hub#473). Bounds
- * second-factor grinding by an attacker who already has the password. Separate
+ * `/login/2fa` rate limiter — per-account/per-half-login floor, keyed
+ * (ip,identity), 5 attempts / 15 min (hub#473). Bounds second-factor grinding
+ * by an attacker who already has the password. RE-KEYED from per-IP to
+ * `compositeKey(ip, userId)` (the shared-egress-IP fix): keyed by the STABLE
+ * userId resolved from the pending-login (NOT the pendingToken, which rotates
+ * on every /login success and would reset the bucket). Behind NAT every 2FA-
+ * enrolled user in a room would otherwise pool into one per-IP bucket. Separate
  * bucket from `/login` so a password failure and a TOTP failure don't share a
- * window — but both are per-IP so rotating egress IPs is the only escape, same
- * as the password floor.
+ * window. The coarse per-IP `authIpCeilingRateLimiter` backstops this floor.
  */
 export const totpRateLimiter = new RateLimiter(TOTP_MAX_ATTEMPTS, TOTP_WINDOW_MS);
 
+/**
+ * Coarse per-IP CEILING rate limiter — 60 attempts / 15 min, keyed by client
+ * IP ONLY. Shared by all interactive auth doors (`/login`, the
+ * `/oauth/authorize` password door, `/login/2fa`) as a backstop against
+ * username-rotation: the per-(ip,identity) floors above stay tight, but an
+ * attacker rotating usernames against one IP would otherwise get a fresh floor
+ * per name. This ceiling caps total per-IP auth volume regardless of identity.
+ * Deliberately generous (matches the signup precedent) so a demo room sharing
+ * one egress IP clears it.
+ */
+export const authIpCeilingRateLimiter = new RateLimiter(AUTH_IP_CEILING_MAX_ATTEMPTS, WINDOW_MS);
+
 /**
  * `POST /account/vault-token/<name>` rate limiter — per-user, 10 attempts /
  * 10 min (friend vault-token mint). Keyed by user-id (session-gated endpoint,
@@ -246,6 +313,16 @@ export const vaultTokenMintRateLimiter = new RateLimiter(
   VAULT_TOKEN_MINT_WINDOW_MS,
 );
 
+/**
+ * `POST /account/setup/<token>` rate limiter — per-IP, 60 attempts / 15 min
+ * (public invite redemption / signup). DELIBERATELY generous: a public
+ * multi-use signup link is redeemed by a room of people sharing one NAT'd
+ * egress IP, so a `/login`-sized cap would 429 legitimate signers mid-demo.
+ * Separate bucket from `/login` so the two never share a window. The invite's
+ * own `max_uses` + expiry are the primary bound; this is the abuse floor.
+ */
+export const signupRateLimiter = new RateLimiter(SIGNUP_MAX_ATTEMPTS, SIGNUP_WINDOW_MS);
+
 /**
  * Backwards-compat shim for hub#188's call sites: the original
  * top-level `checkAndRecord` was the login limiter. New code should
@@ -266,6 +343,20 @@ export function __resetForTests(): void {
   changePasswordRateLimiter.reset();
   totpRateLimiter.reset();
   vaultTokenMintRateLimiter.reset();
+  signupRateLimiter.reset();
+  authIpCeilingRateLimiter.reset();
+}
+
+/**
+ * Compose a per-(ip,identity) rate-limit key. Used by the per-account auth
+ * FLOORs (`/login` + `/oauth/authorize` keyed by username; `/login/2fa` keyed
+ * by userId) so each account behind a shared egress IP gets its own bucket
+ * while the floor still pins to the IP. The identity is trimmed + lowercased so
+ * `'Alice'` and `'alice'` share one bucket — otherwise an attacker could
+ * case-flip a username to mint a fresh 5-slot floor per casing.
+ */
+export function compositeKey(ip: string, id: string): string {
+  return `${ip}|${id.trim().toLowerCase()}`;
 }
 
 /**