The Problem with Passwords

Passwords are the weakest link

The auth course built a solid password system: bcrypt hashing, timing-safe comparisons, rate limiting, account lockout. The security course added brute-force protection, token rotation, and password reset. Despite all of this, passwords remain the weakest part of any auth system.

Credential stuffing: When another service is breached, attackers try those email/password pairs against your app. If your user reused their password (and most people do), the attacker is in. No amount of bcrypt or rate limiting prevents a correct password from working.

Phishing: An attacker creates a lookalike login page. The user enters their password. The attacker now has it. Your server cannot tell the difference between a legitimate login and a login with a phished password.

Shoulder surfing and keyloggers: Someone watches the user type, or malware records their keystrokes. The password is captured at the source.

These attacks succeed because passwords are a shared secret. Both the user and the server know the secret (or its hash). If the attacker learns it from any source, they can authenticate.

The three factors

Authentication factors fall into three categories:

Something you know: Passwords, PINs, security questions. Can be stolen, guessed, or phished.

Something you have: A phone with an authenticator app, a hardware security key, access to an email inbox. The attacker needs physical or digital access to a specific device.

Something you are: Fingerprint, face scan, iris scan. Biometrics are used locally (to unlock a device or key) but not sent to servers.

Single-factor auth uses one category (usually a password). Two-factor auth (2FA) combines two categories. The most common combination: password (something you know) + TOTP code from a phone (something you have).

Passwordless auth replaces the password entirely with a stronger factor: a magic link (something you have — access to the email inbox) or a passkey (something you have — a cryptographic key on your device, often unlocked with something you are — a fingerprint).

What we build in this course

TOTP (Section 2): Time-based one-time passwords. The user scans a QR code with Google Authenticator or Authy. At login, they enter a 6-digit code that changes every 30 seconds. This is the most widely deployed 2FA method.

Recovery codes (Section 3): Backup codes for when the user loses their phone. Generate 10 codes at setup, hash and store them. Each code works once.

Magic links (Section 4): Click a link in your email to log in. No password needed. Simple, familiar (you already know it from password reset), and appropriate for many apps.

Passkeys/WebAuthn (Section 5): The strongest option. The browser generates a public-private key pair. The server stores the public key. Login uses a cryptographic challenge-response. Phishing-resistant by design because the browser checks the origin.

Multi-method auth (Section 6): Combining all of these. A user with password + TOTP + passkey. Fallback chains. The settings page where users manage their auth methods.