Email enumeration on /api/console/signup (F-2 from #26) — gated on email infra

[pulkitpareek18]

Carved out from #26 because the fix needs work that isn't in scope yet.

What

/api/console/signup returns 409 email_taken for existing accounts vs 201 for fresh ones. A botnet within the 10/15min/IP limiter can enumerate the tenant directory (high signal for spear-phishing).

Why we didn't close this in PR for #26

The byte-identical fix per the security review is: return 202 { message: "If new, check your inbox" } regardless of whether the email exists, then send a verification link out-of-band. We have no email infrastructure yet (no SES / Postmark / SMTP wired up), so the verification link can't actually be sent.

The interim option ("uniform 400 invalid_request") also leaks because fresh signups still return 201 — the status-code split is the channel, not the body.

What needs to happen first

1. ADR for email service adoption (likely Postmark or AWS SES). Track via dep-add skill.
2. Wire email delivery + a verification_tokens table.
3. Then this issue's actual fix: return uniform 202; emit the verification link on a worker; let the user complete signup by clicking the link.

Severity holding pattern

This stays at Medium. It's not exploitation-imminent (any pilot buyer doing security diligence today would flag it, but no buyer is in diligence yet). Hard deadline: before first pilot SOW signing.

🤖 Generated with Claude Code

[pulkitpareek18]

Progress — partial mitigation shipped in commit `8a85e33` (PR #33)

Severity: Medium → Low after this PR. Issue stays open until the byte-identical v2 ships.

What's now in place

1. Email infrastructure live — nodemailer + Brevo SMTP wired per ADR-0005. `sendMail()` wrapper, fire-and-forget contract.
2. Timing equalization — `/api/console/signup` duplicate path now runs scrypt to match the fresh path. The ~50ms timing oracle that distinguished "email exists" from "email fresh" is closed.
3. Security-signal email — duplicate signup now sends a "someone tried to sign up with your email" notice to the legitimate account holder out-of-band. Email-was-taken is no longer free intel for an attacker — the real user gets notified.
4. Welcome email on fresh signup — confirms the account is real, points at Quickstart + whitepaper. Does NOT include the API key plaintext (per security-policy §10).

What's still open

5. 201/409 status-code split — the only remaining enumeration channel. Closing it requires a v2 that returns `202` always and sends an email-verification link to complete signup. That's a breaking change to:
   • the dashboard `Signup.tsx` flow (currently expects `{ token, apiKey }` on 201)
   • the Playwright happy path (`dashboard/e2e/happy-path.spec.ts` — currently expects immediate token after signup)
   • the data model (new `pending_signups` table with verification tokens + TTL)

Production deploy pre-reqs

Before the new emails actually deliver:

1. Brevo → Settings → SMTP & API → Authorized IPs → add `104.207.143.14`
2. VPS `/opt/zeroauth/.env` → add the six SMTP/EMAIL_ env vars
3. (Recommended) Hostinger DNS → SPF + DKIM + DMARC records on zeroauth.dev for inbox delivery (otherwise mail may land in spam)

Without (1), `sendMail()` returns `{ok:false, error:'5.7.1 Unauthorized IP'}` and the signup endpoints still 201/409 normally — emails just don't get delivered. Failure mode is loud in the API logs.

Test coverage added

• `tests/email.test.ts` (24) — `sendMail` behavior, `verifySmtp`, template HTML-escape + no-credential-leak assertions
• `tests/console-signup.test.ts` (10) — fresh-signup welcome email queued, duplicate signup 409 + notice to legitimate holder + no tenant created + no body leak + scrypt timing floor

Total tests: 194 → 228.

Next step on this issue

When you're ready for v2 (full byte-identical fix), the work is:

1. Add a `pending_signups` table (`email, password_hash, company_name, verification_token, expires_at, created_at`)
2. Change `/api/console/signup` to: validate + INSERT pending → send verification email → return uniform 202 always
3. Add `POST /api/console/verify-email` that consumes the token, creates the tenant + first API key, returns the dashboard handoff
4. Update `dashboard/src/routes/public/Signup.tsx` to show "check your email" instead of redirecting
5. Update Playwright spec to fetch the verification token via a test-only endpoint (or skip the verification step in test env)

Estimated ~4-6 hours of focused work. Should land in Week 2.

🤖 Generated with Claude Code

[pulkitpareek18]

The F-2 v2 byte-identical signup landed as part of the email-infra
work in #33. POST /api/console/signup now returns the same
202 { status: "pending_verification", message: "..." } regardless
of whether the email is fresh or already taken:

• Fresh email → password hashed, payload parked in pending_signups
  under a 24h-TTL token, verification email sent. Tenant row is
  created only at GET /api/console/verify-signup?token=….
• Email taken → equivalent scrypt cost burned (constant-time match
  for the hash branch), a "someone tried to sign up" notice sent to
  the legitimate holder, same 202 body returned.

See src/routes/console.ts:163 for the v2 handler and
tests/email.test.ts for the welcome + signup-attempted templates.
Closing — the v2 fix is in production and the dashboard already
reads the pending_verification shape (dashboard/src/lib/api.ts
SignupResponse).