Harden sign-up, login and password reset

Paste into any coding agent: Claude Code, Cursor, Codex, Copilot, Windsurf or Cline.

# Harden sign-up, login and password reset

A public launch puts the sign-up and login of the production site in front of bots as well as people. Review how authentication works end to end and fix the gaps attackers try first, without changing how the flows look to a real user.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Replace the auth library or provider.
- Force existing users to reset their passwords.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. Map the auth flows

List sign-up, login, logout, password reset, email change, social or magic-link sign-in, and session handling, with the files for each. Say whether auth is a library or provider (Auth.js, Clerk, Supabase, Devise, Laravel Breeze...) or custom code: with a provider, the job is configuration, not rewriting it.

### 2. Passwords and sessions

- Passwords hashed with a slow algorithm (argon2id, bcrypt or scrypt), never stored or logged in plain text.
- Session cookies `HttpOnly`, `Secure`, `SameSite=Lax` (or `Strict`), with a sensible lifetime; sessions rotated on login and invalidated on logout and password change.
- State-changing requests protected against CSRF (the framework's built-in protection, or SameSite plus an origin check).

### 3. Abuse

Rate limit login, sign-up, password reset and verification emails per IP and per account, with a clear 429. Make login and reset answers the same whether or not the email exists, so accounts cannot be enumerated. If sign-up is open to bots, propose a light challenge (Turnstile, hCaptcha) for me to decide on.

### 4. Reset and verification tokens

Tokens must be random, single-use, short-lived (an hour or less for resets) and stored hashed. A used or expired token gives a clear message and a way to request a new one.

## Done means

- [ ] Passwords use a slow hash and never appear in logs.
- [ ] Session cookies are HttpOnly, Secure and SameSite, and sessions rotate on login.
- [ ] Login, sign-up and reset are rate limited and do not reveal whether an email exists.
- [ ] Reset and verification tokens are random, single-use, short-lived and stored hashed.
- [ ] The sign-up and login flows look and work the same for real users.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.