Practice & Assessment
Test your understanding of Authentication and Session Security
Multiple Choice Questions
6An attacker obtains your bcrypt password database. Each password was hashed with cost factor 10. How long will it take to brute force a 8-character lowercase alphabetic password?
A JWT has the header `{"alg": "none"}` and no signature. Your server uses `jsonwebtoken.verify(token, secret)` without specifying allowed algorithms. What happens?
Why must `req.session.regenerate()` be called on successful login?
What is the primary security advantage of storing JWTs in httpOnly cookies over localStorage?
An attacker sends 1000 login attempts with different passwords to the same account over 10 minutes. Your rate limiter allows 100 requests per IP per 15 minutes. Is the account protected?
In OAuth 2.0, what does the `state` parameter protect against?
Coding Challenges
1Build a Secure Registration and Login API with JWT
Build an Express API with two endpoints: POST /register and POST /login. Registration must: accept email and password, validate email format with Joi, reject passwords shorter than 12 characters, hash the password with bcrypt (cost factor 12), and store email + hash in a SQLite database via better-sqlite3. Login must: look up the user by email, use bcrypt.compare to verify the password (using constant-time comparison, never short-circuit), issue a signed HS256 JWT with userId and role claims and a 15-minute expiry, set the JWT as an httpOnly, secure, sameSite=Lax cookie. Add express-rate-limit allowing 5 POST /login requests per IP per 15 minutes. Write supertest tests verifying: correct credentials return 200, wrong password returns 401, rate limit returns 429 on the 6th attempt. Time estimate: 30 minutes.
Mini Project
Full Authentication System with Secure Sessions and JWT Refresh
Build a complete authentication system with the following components: (1) Registration: bcrypt (cost 12) password hashing, Joi validation (email, password min 12 chars, at least one number and symbol). (2) Login: rate limited to 5 attempts per IP per 15 minutes AND 5 attempts per account stored in memory/Redis with 15-minute lockout; on success, regenerate session, issue a 15-minute JWT access token as httpOnly cookie, and a 7-day refresh token stored in DB. (3) Refresh endpoint: POST /auth/refresh — validates the refresh token from the httpOnly cookie, issues a new access token, and rotates the refresh token (invalidate old one, issue new one). (4) Logout: destroys session, clears cookies, invalidates refresh token in DB. (5) A protected GET /profile endpoint that validates the JWT with algorithm explicitly set to HS256. Deliverable: working Express app with supertest tests covering happy path, expired token, invalid token, and rate limit scenarios.