Auth abuse protection: rate-limit login/register and enforce a minimum password length

[paccloud]

What to build

Protect the public auth endpoints. Today registration accepts any non-empty username/password (one character works), and neither login nor register has any rate limiting — leaving the door open to brute force and credential stuffing on both the serverless API and the Express dev server.

Decision needed first: which rate-limit backing store to use on Vercel serverless (e.g. Upstash/Vercel KV sliding window vs. a Postgres-based limiter vs. an edge middleware approach). Express can use an in-memory limiter locally.

Then implement: a burst limit on login/register, and a minimum password length (suggest 8 characters) enforced at registration with a clear error message.

Context: AUDIT_REPORT.md §3.5 and task 1.5 (branch claude/repo-audit-improvement-ozhlau).

Acceptance criteria

• Infra decision recorded for the serverless rate-limit store
• A burst of ~20 rapid login attempts from one client receives 429 responses
• Registration rejects passwords under the minimum length with a clear error
• Both backends enforce the same rules; normal login UX is unaffected

Blocked by

None - can start immediately (decision first, then implementation)

[paccloud]

This was generated by AI during triage.

Re-triage: reopened as ready-for-human

Unchanged on main (d6ee642), and it now also covers the auth-consolidation leftover from #15:

• Legacy register is orphaned but still live. /api/register (bcrypt + JWT) accepts any non-empty password and has no throttling. The UI now signs up through Firebase and no longer calls it, but it's still deployed.
• Legacy login is actively used and unthrottled. The login form still calls /api/login for non-email usernames and as a fallback when Firebase rejects an email. handleLogin has no attempt counting, lockout, or backoff. It does return a uniform 401, so usernames can't be enumerated.
• The only limiter is local-only. Express has a global 300 requests/min per IP on /api. It's far too loose for credential stuffing, and the production Vercel functions have nothing.

Why this can't go to an agent yet: two owner decisions come first.

1. Retire legacy registration (return 410), or keep it with a password policy? Retiring it is likely, since sign-up is on Firebase. The wider question is when to retire legacy password auth altogether, and how username-only accounts, which may have no email, move to Firebase.
2. How to rate-limit on serverless: an app-level Neon-backed attempts table (a schema change), or Vercel WAF/Firewall rules (dashboard only)?

Firebase's own password policy and abuse settings live in the console and need a manual check. Once decided, the brief below is agent-ready.

Agent Brief

Category: bug
Summary: Stop brute-force and weak-password abuse on the legacy username/password register and login endpoints.

Current behavior: Legacy register creates accounts with any non-empty password. Legacy login allows unlimited attempts. Neither production function is rate-limited.

Desired behavior (pending the decisions above):

• Registration: either (A) retired, so the endpoint returns 410 Gone pointing users to the normal sign-up, or (B) a minimum password length (e.g. at least 8, with a clear 400) enforced in the shared handler so both backends get it. If kept, also rate-limit it per IP.
• Login: failed legacy logins are limited per username and per client IP within a sliding window (e.g. 5–10 failures per 15 minutes). Over the limit, return 429 with Retry-After, without revealing whether the username exists. A success clears that username's counter. The limit needs a shared store (a DB table via the DbAdapter seam, or the platform firewall), not in-process memory.
• Frontend: a 429 from legacy login shows a clear "too many attempts" message.

Key interfaces: handleRegister(input, db), handleLogin(input, db, config), the DbAdapter interface (e.g. methods to record and count failed attempts), the Neon and SQLite adapters, the login/register functions in AuthContext, and the Express apiRateLimit.

Acceptance criteria:

• Legacy register returns 410, or rejects passwords under the chosen minimum with 400, and behaves the same on both backends
• Legacy login returns 429 after N failures for the same username within the window, and for the same IP across usernames
• A 429 response has the same shape whether or not the username exists
• A successful login resets the username's failure counter
• Throttle state survives across separate serverless invocations (tested through the adapter, not module memory)
• Handler unit tests cover the throttle and the policy or 410 behavior
• The UI shows a clear message on a 429

Out of scope:

• Firebase console password policy and abuse settings
• Migrating legacy accounts to Firebase (a separate follow-up once decision 1 is made)
• Rate limiting non-auth endpoints

---

Generated by Claude Code