Introduction
Despite the rise of biometrics and hardware security keys, passwords remain the most widely used authentication method in the world. Because of that, both how systems store passwords and how users choose them are critical security concerns. A single weak link — a plaintext password database or a reused, guessable password — can lead directly to a breach affecting millions of accounts.
Cricket analogy: Despite the rise of Hawk-Eye and DRS technology, the basic front-foot no-ball call by the umpire remains fundamental to the game, and a single missed call, like a single weak password, can swing an entire match.
Explanation
Well-designed systems never store passwords in plaintext. Instead, when a user creates a password, the system runs it through a one-way cryptographic hash function, producing a fixed-length string that cannot practically be reversed back into the original password. When the user logs in later, the system hashes the entered password again and compares the two hashes; if they match, the password is correct. Because identical passwords would otherwise produce identical hashes — letting an attacker spot which users share a password, or precompute 'rainbow tables' of common password hashes — secure systems add a salt: a unique, random value generated per user and stored alongside the hash. The salt is combined with the password before hashing, so even two users with the exact same password end up with completely different stored hashes. Modern systems also use hashing algorithms specifically designed to be slow and computationally expensive (such as bcrypt, scrypt, or Argon2) rather than fast general-purpose hashes, which makes brute-force guessing attacks far more costly for an attacker even if the password database is stolen.
Cricket analogy: Storing a password in plaintext is like writing the team's signal codes openly on a whiteboard; hashing scrambles it into an unreadable form, and salting ensures that even two players choosing the same code end up with different scrambled versions.
On the user side, password guidance has shifted substantially from older advice. Current NIST-aligned guidance emphasizes length over arbitrary complexity: a long passphrase (such as several random unrelated words) is generally both easier to remember and harder to crack than a short password stuffed with mandatory symbols and numbers. Forced periodic password expiration and rigid complexity rules (requiring at least one uppercase letter, one digit, one symbol) are now discouraged by modern guidance because they tend to push users toward predictable patterns and minor variations of the same password. The most important practical habits are: use a unique password for every site so that one breached service cannot compromise accounts elsewhere, and use a password manager to generate and store strong, random, unique passwords so users are not forced to memorize dozens of them.
Cricket analogy: Modern coaching now favors a batsman mastering a few reliable, well-practiced shots over memorizing dozens of rarely-used ones, just as NIST now favors a long memorable passphrase over forced complex symbol rules.
Example
Insecure storage (NEVER do this):
username: alice password: Summer2024! <- stored in plaintext
Secure storage:
username: alice
salt: 8f2c91a4... (random, unique per user)
hash: bcrypt(salt + password) -> $2b$12$KIXQ...
Login check:
1. Look up alice's stored salt
2. Compute bcrypt(salt + entered_password)
3. Compare to stored hash - match means correct password
4. Plaintext password is never stored or loggedAnalysis
Salted, slow hashing matters enormously in the aftermath of a breach: if attackers steal a database of properly salted bcrypt or Argon2 hashes, they cannot simply look up precomputed rainbow tables, and each guess must be computed individually and slowly, making large-scale cracking impractical for strong passwords. Conversely, breaches of databases using fast, unsalted hashes (or worse, plaintext) have historically led to immediate mass credential exposure. On the user side, password reuse is the single biggest amplifier of breach damage — when one low-security site is breached, attackers automatically try the same email/password combination against banks, email providers, and other high-value targets in an attack called credential stuffing. A password manager combined with unique passphrases per site directly neutralizes this attack pattern, which is why it is now the leading practical recommendation for individuals.
Cricket analogy: A properly salted, slowly-computed password hash is like a well-guarded pitch report that even a rival team can't crack quickly, while a reused password across accounts is like using the same signal code across every match, letting one leak compromise them all.
Key Takeaways
- Passwords must never be stored in plaintext; systems should store a salted hash produced by a slow, purpose-built algorithm such as bcrypt, scrypt, or Argon2.
- A unique random salt per user prevents identical passwords from producing identical hashes and defeats precomputed rainbow-table attacks.
- Modern guidance favors long, unique passphrases over rigid complexity rules, plus using a password manager and never reusing passwords across sites.
Practice what you learned
1. Why do secure systems add a random salt before hashing a password?
2. Which of the following is current, NIST-aligned password guidance?
3. Why are algorithms like bcrypt or Argon2 preferred over fast general-purpose hash functions for password storage?
4. What is the main security benefit of using a unique password for every website?
Was this page helpful?
You May Also Like
Authentication Basics
Learn how systems verify identity through authentication, how it differs from authorization, and the three factor categories used to prove who you are.
Multi-Factor Authentication
Understand how MFA combines multiple distinct authentication factor categories to dramatically reduce the risk of account takeover.
Hashing and Digital Signatures
Understand one-way cryptographic hashing and how digital signatures use hashing plus private keys to prove integrity and authenticity.
Session Management Security
How to protect user sessions with secure cookie attributes and defenses against fixation and hijacking.