How to Generate Strong Passwords and Understand Password Hashing
Passwords are the front door of almost every online account and application. Yet most breaches that make the news come down to one of two problems: users chose weak passwords, or developers stored them incorrectly. This guide covers both sides — how to generate strong passwords that are genuinely hard to crack, and how password hashing works so that even if a database is stolen, the actual passwords remain protected.
What Makes a Password Strong?
A password's strength comes down to one thing: how long it would take an attacker to guess it. Attackers use two main approaches: dictionary attacks (trying common words, names, and known leaked passwords) and brute-force attacks (trying every possible combination of characters).
The factors that determine how resistant a password is to both types of attack are:
Length — This is the single most important factor. Each additional character multiplies the number of possible combinations an attacker must try. An 8-character password using only lowercase letters has about 200 billion possible combinations — a modern GPU can try those in under a minute. A 16-character password using the same character set has 43 quadrillion combinations — orders of magnitude harder.
Character set size — Using uppercase letters, numbers, and symbols alongside lowercase letters dramatically increases the size of the character set an attacker must consider. A lowercase-only password uses a 26-character set. Add uppercase and you have 52. Add digits: 62. Add common symbols: around 94. The difference between a character set of 26 and 94 is enormous when raised to the power of the password length.
Randomness — Even a long password with diverse characters is weak if it follows a predictable pattern. Password123! meets most password policy requirements but appears near the top of every dictionary attack list because millions of people choose it. True randomness — characters chosen without any human-meaningful pattern — is what defeats dictionary attacks.
Uniqueness — A strong password used across multiple sites is still a vulnerability. If one site is breached and your password is exposed, every other site where you use that password is now at risk. Each account needs its own unique password.
What Makes a Password Weak?
Certain patterns appear so frequently in leaked password databases that any halfway competent attacker tries them immediately:
- Common words and names:
sunshine,michael,dragon,password - Number suffixes:
password1,qwerty123,football2024 - Keyboard patterns:
qwerty,123456,zxcvbn,qwertyuiop - Dates:
01/01/1990,19900101,birthdayfollowed by a year - Leet-speak substitutions:
p@ssw0rd,s3cur1ty— attackers know these patterns - The name of the service with numbers:
Facebook2024,Gmail123
Password cracking tools come pre-loaded with billions of these patterns. A password that seems creative to a human looks entirely predictable to a script.
How to Generate a Strong Password
The most reliable way to generate a strong password is to use a tool that sources entropy from a cryptographically secure random number generator, rather than letting a human choose. Humans are bad at randomness — we avoid awkward character combinations, we subconsciously follow patterns, and we choose things we can remember.
The UUID Generator on this site produces UUIDs (Universally Unique Identifiers) — 128-bit random values expressed as a 36-character hex string like 550e8400-e29b-41d4-a716-446655440000. While not designed specifically as a password tool, a random UUID is extremely strong as a password and guaranteed to be unique.
For a password that is both strong and memorable, a better approach is a passphrase — four or more random common words strung together. correct horse battery staple (from the famous XKCD comic) is both long (28 characters) and easy to remember. The Random Word Generator on this site can generate lists of random words that you can combine into a passphrase.
For general best practice: aim for at least 16 characters, use a mix of character types, generate it randomly rather than inventing it yourself, and store it in a password manager (1Password, Bitwarden, Dashlane, or the one built into your browser) so you never need to remember it.
What Is Password Hashing?
When a user sets a password, a responsible application never stores the password itself. Instead, it stores a hash — the output of a one-way mathematical function applied to the password. When the user logs in later, the application hashes what they typed and compares it to the stored hash. If they match, the password is correct.
A hash function has two critical properties:
- Deterministic — the same input always produces the same output
- One-way — given the output (the hash), it is computationally infeasible to reverse it back to the input
This means that even if an attacker steals a database full of password hashes, they cannot simply reverse the hashes to get the original passwords. To crack a hash, they must try candidates (from a dictionary or by brute force), hash each one, and see if it matches — a much slower process than working with the plain passwords directly.
Different Types of Hash Functions
Not all hash functions are equally suited for passwords. There is an important distinction between general-purpose cryptographic hashes and password hashing functions.
General-Purpose Hashes (SHA-256, SHA-512, MD5)
These are designed to be fast. A modern computer can compute billions of SHA-256 hashes per second. For their intended purpose — verifying file integrity, signing documents, building blockchains — speed is a feature. For storing passwords, speed is a vulnerability. The faster an attacker can try candidate passwords, the more quickly they can crack hashes.
MD5 in particular should never be used for passwords — it is not only fast but also has known cryptographic weaknesses.
Use SHA-256 and SHA-512 for: verifying file checksums, signing data, generating HMACs for API authentication. Do not use them for storing passwords.
The Hash Generator tool on this site generates MD5, SHA-1, SHA-256, and SHA-512 hashes — useful for file verification, checksums, and any application where you need a fast, consistent digest of some data.
Password-Specific Hashing Functions (bcrypt, scrypt, Argon2)
These are designed to be slow and memory-intensive. Deliberately. The idea is that hashing one password takes a fraction of a second — imperceptible to a legitimate user — but multiplies the time and hardware required for an attacker trying millions of candidates.
bcrypt is the most widely deployed password hashing algorithm. It includes a work factor (cost factor) that you can increase as hardware gets faster, keeping the time-per-hash consistent over time. It also automatically generates and stores a random salt.
scrypt adds a memory-hardness requirement on top of computational hardness, making GPU-based cracking attacks even less efficient.
Argon2 is the most modern of the three, winning the Password Hashing Competition in 2015. It provides the best defence against GPU and ASIC cracking attacks.
If you are building an application that stores user passwords, use bcrypt, scrypt, or Argon2. Never use MD5, SHA-1, or even SHA-256 directly for password hashing.
What Is a Salt and Why Does It Matter?
A salt is a random value that is generated uniquely for each password and combined with the password before hashing. The salt is stored alongside the hash in the database.
Without salts, an attacker who steals a database can attack all hashes simultaneously using rainbow tables — precomputed lookup tables that map hashes back to their inputs. A rainbow table for MD5 can crack most common passwords in milliseconds.
With salts, rainbow tables become useless because each hash was computed with a different random input. The attacker must crack each hash individually, which multiplies their work by the number of users.
Modern password hashing functions like bcrypt automatically generate and embed the salt, so if you use them, salting is handled for you.
Checking if a Password Has Been Compromised
Beyond generating strong passwords, it is worth knowing whether a password you are considering has appeared in a previous data breach. The Have I Been Pwned database contains over 10 billion compromised passwords from known breaches. Any password in that database should never be used, regardless of how strong it looks.
Many password managers now integrate this check automatically, flagging passwords that appear in known breach lists when you create or update them.
Verifying File Integrity with Hashes
Hashes are used for more than passwords. When you download a large file — an operating system image, a software installer, a database backup — the provider often publishes a hash of the file alongside the download link. After downloading, you compute the hash of the file you received and compare it to the published value.
If the hashes match, the file arrived exactly as intended — no corruption in transit, no tampering. If they do not match, something went wrong and you should not use the file.
The File Checksum tool on this site computes MD5, SHA-1, SHA-256, and SHA-512 checksums for any file you upload, entirely in your browser. Your file never leaves your computer, which matters when you are verifying sensitive files like configuration backups or credentials archives.
Best Practices Summary
For users:
- Use a password manager — you only need to remember one strong master password
- Use a unique password for every account
- Aim for 16+ characters generated randomly or as a 4+ word random passphrase
- Enable two-factor authentication wherever it is available
For developers:
- Never store plain-text passwords, ever
- Use bcrypt, scrypt, or Argon2 for password hashing — not MD5, SHA-1, or SHA-256
- Ensure salts are unique per user (bcrypt does this automatically)
- Use SHA-256 or SHA-512 for checksums and data integrity verification, not for passwords
- Increase the bcrypt work factor as hardware improves — aim for a hashing time of 100–300ms
Conclusion
Password security sits at the intersection of user behaviour and developer responsibility. Users need to choose passwords that are long, random, and unique — tasks best delegated to a password manager. Developers need to store passwords using a slow, salted hashing function and never expose plain-text credentials in logs, responses, or databases. When both sides of the equation are done correctly, a stolen database becomes nearly worthless to an attacker.
Use the Hash Generator to compute checksums and verify data integrity, the UUID Generator or Random Word Generator to create strong random passwords or passphrases, and the File Checksum tool to verify the integrity of files you download.