User Authentication for SaaS Backend

Problem/Feature Description

A B2B SaaS company's security audit found two critical issues with their Fastify backend. First, passwords were being stored with a weak hashing algorithm (MD5) that an attacker could reverse within minutes using a GPU. Second, the login endpoint had no rate limiting — the security team demonstrated a credential stuffing attack that attempted 10,000 login combinations in under 30 seconds. The company runs multiple backend instances behind a load balancer, so any rate limiting solution must work across all instances consistently.

The security lead has mandated a complete rewrite of the authentication module before the next release. The new system must use an industry-standard memory-hard hashing algorithm with parameters strong enough to resist modern GPU attacks, and must have distributed rate limiting that actually works in a horizontally-scaled deployment.

The system should issue short-lived access tokens so that revocation is practical. The existing user store is a simple in-memory map for this implementation.

Output Specification

Create a Fastify authentication module with the following routes:

• POST /auth/register — create a new user account (name, email, password), returns 201
• POST /auth/login — validate credentials and return tokens, returns 200 with { accessToken, refreshToken } or 401
• GET /auth/me — return the current authenticated user's profile (requires valid access token in Authorization header), returns 200 or 401

Files to produce:

• src/app.ts — Fastify application setup
• src/plugins/auth.ts — authentication plugin
• src/routes/auth.ts — route handlers
• package.json — with all dependencies listed

The implementation should document in comments or a SECURITY.md file what rate limiting configuration would be needed in production (even if the actual Redis connection string is a placeholder). Do not implement OAuth or session-based auth — JWT only.