Practice & Assessment
Test your understanding of Password Reset and MFA
Multiple Choice Questions
6A POST /auth/forgot endpoint returns 'Email not found' for unknown emails and 'Reset link sent' for known ones. What does this enable?
Why is TOTP considered more secure than SMS-based OTP for two-factor authentication?
After the password phase of a two-step login succeeds for an MFA-enabled user, what should be stored in the session?
Backup codes should be stored in the database as:
What does the window parameter in speakeasy.totp.verify do?
When should you display backup codes to a user?
Coding Challenges
1Build a complete password reset flow
Implement two endpoints. POST /auth/forgot accepts an email, always returns 200 with the same message, and if the user exists stores a crypto.randomBytes(32) hex token with a 1-hour expiry in a module-level Map keyed by token. POST /auth/reset accepts token and newPassword, validates the token exists and has not expired, hashes the new password with bcrypt, updates the user record in the mock database, removes the token, and returns 200. Both endpoints must prevent account enumeration. Input: JSON body with email or token+newPassword. Output: JSON status messages. Constraint: no real database, use module-level objects. Estimated time: 20–25 minutes.
Mini Project
Full Auth System with MFA and Password Reset
Extend the JWT-based auth API from Module 3 with the complete MFA and password reset features from this module. Required features: POST /auth/forgot and POST /auth/reset with token stored in PostgreSQL (or mock); POST /auth/mfa/setup returns a QR code URL and temporary secret; POST /auth/mfa/confirm verifies the user's first code, saves the secret, and returns 10 single-use backup codes (store hashed); two-phase login where MFA-enabled users must POST /auth/mfa with a TOTP code after password verification; POST /auth/backup-code for recovery during the MFA phase. Each endpoint must have appropriate rate limiting. Document the full API in a README with curl examples.