Password Security: How to Generate, Store, and Audit Strong Passwords
Quick Answer
Generate 16+ character random passwords with our Password Generator, never reuse them, and store them in a password manager. On the server, hash with bcrypt (work factor 12+), scrypt, or Argon2id — never MD5 or SHA-256. Audit breaches via Have I Been Pwned's k-anonymity API. Never transmit or log plaintext passwords.
Introduction
Weak, reused, and improperly stored passwords cause the majority of account takeovers. This guide solves four concrete problems: (1) generating passwords with enough entropy to resist brute force, (2) hashing passwords with a slow KDF instead of a fast hash, (3) avoiding reuse across services, and (4) auditing leaked credentials. Each solution is actionable and tool-backed.
Step by Step
-
Generate a high-entropy password
Use the Password Generator to create a 16+ character password mixing upper, lower, digits, and symbols. Entropy = log2(charsetSize^length); a 16-char alphabet of 94 symbols gives ~105 bits, which is infeasible to brute force even at 10^12 guesses/second.
-
Never reuse passwords across services
Reusing one password means a single breach compromises every account sharing it. Generate a unique password per service and store them in a password manager (Bitwarden, 1Password, KeePassXC). The master password is the only one you need to remember — make it a long passphrase.
-
Hash passwords with a slow KDF on the server
Never store passwords with MD5, SHA-1, or raw SHA-256 — they are too fast, and GPUs can try billions per second. Use bcrypt with work factor 12+, scrypt with N=2^17, or Argon2id with 64MB memory. These KDFs are deliberately slow and memory-hard to defeat GPU/ASIC attacks.
-
Use a salt to defeat rainbow tables
A salt is a unique random value per password, prepended or combined before hashing. It ensures identical passwords produce different hashes, making precomputed rainbow tables useless. bcrypt and Argon2 generate and embed the salt automatically — do not roll your own.
-
Audit for breached passwords
Before accepting a password, check it against the Have I Been Pwned API using the k-anonymity protocol: send only the first 5 characters of the SHA-1 hash, receive the list of matching suffixes, and compare locally. This never reveals the full password to the API.
Examples
Strong generated password (16 chars, ~105 bits entropy)
Input: Length 16, all character classes
Output: K9$mP2#vL7@nQ4!x (random, unique, never reused)
Passphrase for a master password (memorable + strong)
Input: 4 random common words
Output: correct-horse-battery-staple (~44 bits but easy to remember; use 5-6 words for ~60+ bits)
bcrypt hash of a password (work factor 12)
Input: password123 with bcrypt cost 12
Output: $2b$12$N9qo8uLOickgx2ZMRZoMy.MrqKQp7vqB4V1e5sTq7vqB4V1e5sTq (salt + cost + hash embedded)
Common Problems
- Using MD5 or SHA-256 for password hashing: both are fast hashes. A modern GPU computes ~10 billion SHA-256/s, cracking an 8-char password in minutes. Always use bcrypt, scrypt, or Argon2id.
- Reusing one password across sites: a breach at the weakest site leaks the password for every site. Generate unique passwords and store them in a manager.
- Storing passwords in plaintext or reversible encryption: if the database leaks, every account is instantly compromised. Hashing is one-way and irreversible — even the server cannot recover the original.
- Low work factor in bcrypt: cost 4 was fine in 2002; in 2026 use cost 12+ (roughly 4096 iterations). Re-hash on login to upgrade old hashes without forcing a password reset.
Tips
- Aim for at least 100 bits of entropy for high-value accounts — that is 16 random characters from a 94-symbol alphabet, or 6 random diceware words.
- Turn on two-factor authentication (TOTP or hardware key) for every account that supports it — a strong password alone is not enough if the password is phished.
- Use our Password Generator's 'exclude ambiguous characters' option (0/O, 1/l/I) when passwords will be read aloud or typed from print.
- Rotate passwords only after a confirmed breach, not on a fixed schedule — forced rotation drives users to predictable patterns like Spring2026!.