Email + Password Auth

This module assumes Auth Fundamentals@markdowners/auth-fundamentals — the hashing, session, and rate-limiting rules there apply in full here. What follows is specific to the email+password flow itself.

Signup

• Validate email format server-side (a real parser/regex, not just "contains @"), and always verify ownership via a confirmation link before treating the account as fully active — unverified accounts must stay restricted.
• Check for existing accounts by normalized email (lowercased, and ideally with common alias tricks like +tag addressing considered) to avoid accidental duplicate accounts, but never reveal in the signup response whether an email is already registered — respond identically either way and let the "confirm your email" vs. "you already have an account" distinction happen only inside the (already-authenticated) email itself.

Login

• Compare the submitted password against the stored hash using the hashing library's constant-time comparison function — never compare hashes with a standard ===/==, which can leak timing information about where the mismatch occurs.
• Return the same generic error ("invalid email or password") whether the email doesn't exist or the password is wrong — a distinct "no account with that email" error is a user-enumeration vector.
• On successful login, regenerate the session identifier (don't reuse a pre-login session ID) to prevent session fixation.

Password change

• Require the current password to set a new one (except in the password-reset-via-email flow, which uses a reset token instead) — an authenticated session alone shouldn't be sufficient to silently change credentials, since a hijacked-but-not-yet-detected session could otherwise lock the real owner out permanently.
• Invalidate all other active sessions when a password is changed, unless the user explicitly opts to keep them — a password change is frequently a response to suspected compromise, and old sessions should not survive it by default.

Rate limiting and lockout

• Rate-limit login attempts per account and per IP independently, and consider a temporary account lockout or exponential backoff after repeated failures — but always pair lockout with a legitimate recovery path so it can't be weaponized to lock out a real user by an attacker deliberately failing their login.

Storage

• Store only the password hash, never the plaintext, never a reversible encryption of it — and never log the raw password value anywhere, including in request-body debug logs, even temporarily.

Edge cases

• Handle email case-insensitivity consistently at every touchpoint (signup, login, password reset) — a user who signed up with Name@Example.com must be able to log in with name@example.com.
• Trim leading/trailing whitespace from both email and password fields before comparing — pasted credentials frequently carry stray whitespace.