Password Login Systems

Storing Passwords

Never store a password, and never encrypt one — encryption is reversible, which is exactly what you do not want. Store a one-way hash produced by a slow, salted, purpose-built algorithm. PHP's password_hash() does this correctly with a single call, defaulting to bcrypt and supporting Argon2id:

<?php

declare(strict_types=1);

$hash = password_hash('correct horse battery staple', PASSWORD_DEFAULT);

var_dump(password_verify('correct horse battery staple', $hash)); // true
var_dump(password_verify('wrong guess', $hash));                  // false

// The stored hash includes the algorithm, cost, and a random salt,
// so no separate salt column is needed and verification is self-describing.

Three properties matter. The hash is slow by design (a tunable cost factor), so an attacker who steals the database can try only thousands of guesses per second instead of billions. It is salted automatically and uniquely per password, so identical passwords produce different hashes and precomputed rainbow tables are useless. And it is self-describing: password_needs_rehash() lets you upgrade the cost or algorithm transparently as hardware improves, on the user's next successful login. Use password_verify() for the comparison — it is constant-time, so it does not leak information through how long a mismatch takes.

Password Policy That Helps

Modern guidance (NIST) inverted the old advice. Length is what matters — enforce a generous minimum (8 absolute, 12+ encouraged) and a high maximum (so passphrases and password managers work), and stop there. Do not impose composition rules ("one uppercase, one symbol"), do not force periodic rotation, and do not offer password hints or knowledge-based security questions — every one of those makes passwords weaker or more predictable in practice. The one screen worth adding is a check against known-breached passwords (via a k-anonymity API like Have I Been Pwned), because a password's presence in a breach corpus is the single best predictor that it will fall to credential stuffing.

Defending The Login Endpoint

A correct hash protects stolen data; it does nothing against someone guessing at the live login form. That defense is rate limiting and it is covered in depth by the rate limiting lesson, with one authentication-specific warning repeated here: prefer throttling and escalating friction over hard account lockouts, because an attacker who can lock any account by failing logins has turned your control into a denial-of-service weapon. Count failures per account and watch for the credential-stuffing signature of many accounts failing from a spread of addresses.

Two more front-door essentials: the login form is a state-changing POST and needs CSRF protection, and the whole exchange must be over HTTPS so the password is never on the wire in clear. On success, regenerate the session ID (covered in the token implementation lesson) to prevent session fixation.

The Reset Path Is Part Of The System

A password login system is not complete without its recovery flow, and that flow is a full authentication path — see the magic links lesson, whose single-use, expiring, unguessable-token mechanics are exactly what a password reset requires. Securing the login to bank-grade standards and the reset to "email a six-digit code that never expires" is the most common way password systems are actually broken.

What To Check

Before moving on, make sure you can:

• explain why passwords are hashed with a slow salted algorithm, never encrypted
• use password_hash, password_verify, and password_needs_rehash correctly
• state modern password policy: length over composition, no forced rotation, breach-check
• defend the login endpoint with throttling that cannot be weaponized
• name the login-form essentials: HTTPS, CSRF, session regeneration
• explain why the reset flow must be as strong as the login

What You Should Be Able To Do

After this lesson, you should be able to build a password login that stores credentials safely, resists both offline cracking and online guessing, avoids counterproductive policy, and secures its recovery path to the same standard as its front door.