Let’s talk about password recovery mechanisms - specifically, why some old approaches are dangerous and what the modern best practice looks like.

The Bad Old Days

Insecure patterns from the past included:

  • Plain text storage - Allowing users to retrieve their original passwords
  • Symmetric encryption - Same problem, just with extra steps
  • Security questions - “What’s your mother’s maiden name?” (easily guessable or social-engineerable)

The Modern Approach: Password Reset

Instead of retrieving passwords, implement a secure reset flow:

The Process

  1. User requests password reset via username or email
  2. Application generates a unique, cryptographically random token
  3. Token is stored in the database with an expiration timestamp
  4. User receives an email with a reset link containing username and token
  5. Application validates the request
  6. User sets a new password

Validation Checklist

Before allowing a password reset, verify:

  • ✅ Valid username/token pairing
  • ✅ Token hasn’t expired (typically 24-hour window)
  • ✅ Token hasn’t been previously used (one-time use)

Why Not Send Auto-Generated Passwords?

Think about what happens if an attacker gains access to someone’s email. They could:

  1. Request password resets for various services
  2. Search for “password” in the email archive
  3. Access accounts using the auto-generated passwords found

By requiring users to actively set their new password on your site, you add an extra layer of protection.

Implementation Tips

CREATE TABLE password_resets (
    id INT PRIMARY KEY AUTO_INCREMENT,
    user_id INT NOT NULL,
    token VARCHAR(64) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    used_at TIMESTAMP NULL,
    expires_at TIMESTAMP NOT NULL
);

Always hash the token before storing it (just like passwords), and invalidate it immediately after use.