How to Choose the Right Password or Hash for the Job
It's common to see "hash" used as one generic term for several very different operations: generating a strong password, hashing a password for storage, and hashing a file or string for integrity checking. Each has a correct tool and a wrong one, and picking the wrong one — most commonly, storing passwords with a fast general-purpose hash like MD5 or plain SHA-256 instead of a slow password-hashing algorithm — is one of the most common real-world security mistakes.
Key Takeaways
- Generating a password and hashing a password are different steps: one creates a secret, the other stores it safely
- MD5 and SHA-256 are fast, general-purpose hashes — fast is exactly the wrong property for password storage, since it makes brute-forcing cheap
- bcrypt (and similarly, Argon2/scrypt) is deliberately slow and includes a built-in salt, which is why it's the correct choice for password storage
- A password strength checker estimates how hard a password is to guess; it is not a substitute for hashing it correctly at rest
- Use MD5/SHA-256 for what they're actually good at — checksums, cache keys, deduplication — not for anything involving secrets
1. Generating a password: randomness is the whole job
A password generator's only job is producing a string that's hard to guess — long enough, from a large enough character set, generated with a cryptographically secure random source. This step has nothing to do with hashing; it produces the plaintext secret a user will actually type or a system will actually store (temporarily) before it gets hashed for storage.
2. Checking password strength: a guidance tool, not a security control
A password strength checker estimates how resistant a password is to guessing and common cracking patterns (dictionary words, keyboard patterns, reused breach passwords). It's useful for giving users feedback at signup, but it is not what protects a password at rest — that's the hashing step. A strong password stored with a weak hash is still a weak system.
3. Hashing a password for storage: slow, salted, purpose-built
Passwords must be hashed with an algorithm specifically designed for password storage — bcrypt, Argon2, or scrypt — never with a general-purpose fast hash like MD5 or plain SHA-256/SHA-1. These password-hashing algorithms are deliberately slow and computationally expensive (tunable via a "work factor" or "cost" parameter) specifically to make brute-force and rainbow-table attacks impractical, and they automatically generate and store a unique salt per password so identical passwords don't produce identical hashes.
4. Hashing for integrity, not secrecy: MD5 and SHA-256's real job
MD5 and SHA-256 are fast by design, which makes them well-suited for checksums, deduplication, cache keys, and verifying a file wasn't corrupted in transit — none of which involve a secret an attacker is trying to recover. MD5 additionally has known collision weaknesses that rule it out even for security-adjacent integrity checks (like verifying software hasn't been tampered with); SHA-256 is the safer general-purpose choice there.
5. Match the tool to the actual threat model
The deciding question is: "if someone obtains this hash, what can they do with it?" If the answer involves recovering a user's real password (password storage), you need bcrypt/Argon2. If the answer is "at worst, they see this file has changed" (checksums, cache keys), a fast hash like SHA-256 is appropriate and more efficient. Using a slow password hash for high-volume cache keys wastes CPU for no security benefit; using a fast hash for password storage is a genuine vulnerability.
Common Mistakes to Avoid
- ✗Storing user passwords with MD5 or plain SHA-256 instead of bcrypt/Argon2 — this is one of the most common real-world breach-severity multipliers
- ✗Treating a "strong" password strength score as sufficient protection on its own, independent of how it's hashed at rest
- ✗Using bcrypt for high-frequency, non-secret operations like cache keys, where its deliberate slowness only adds unnecessary CPU cost
- ✗Reusing the same salt across users, or trusting a hash implementation that doesn't generate a unique salt automatically
- ✗Assuming hashing and encoding (like Base64) are the same category of operation — they solve entirely different problems
Frequently Asked Questions
Why is MD5 wrong for storing passwords if it still produces a unique-looking hash?▾
MD5 is fast — designed to compute billions of hashes per second on modern hardware — which makes brute-force and precomputed rainbow-table attacks cheap against it. Password-hashing algorithms like bcrypt are deliberately slow and salted specifically to make that kind of attack impractical, which is the property that actually matters for password storage.
What's the difference between hashing and encrypting a password?▾
Hashing is one-way — there is no way to recover the original password from its hash, which is exactly what you want for storage, since you only ever need to check a match, never retrieve the original. Encryption is two-way and reversible with a key, which is the wrong property for password storage precisely because a leaked key would expose every password.
Is a long, random password from a generator enough on its own?▾
It's necessary but not sufficient. A strong, randomly generated password still needs to be hashed correctly (bcrypt/Argon2) when stored — a great password protected by a weak storage hash is still vulnerable if the password database is ever leaked.
Related Tools
Related Guides
How to Validate JWT Tokens Without Exposing Secrets
How to safely inspect a JWT's header and payload during debugging without pasting live tokens or signing secrets into tools that could log or leak them.
How to Safely Decode and Inspect Base64 and Encoded Strings from Untrusted Sources
Base64 is encoding, not encryption — anyone can decode it. Here's how to inspect encoded strings from logs, tokens, or webhook payloads without assuming they're safe or private.
Last reviewed: 2026 · Written and verified by the Dev Utilities team · Editorial policy
Report an issue with this guide →