Most people think a strong password is simply a normal password with more decoration: add a capital letter, replace an “a” with @, append 123!, and the account is supposedly secure. From an attacker’s perspective, that assumption is outdated.
Password cracking is not primarily about someone sitting at a keyboard guessing what you typed. Modern cracking is automated, parallelized, and optimized around the predictable ways humans construct passwords. Attackers use dictionaries, leaked credential databases, mutation rules, probabilistic models, and GPUs capable of evaluating enormous numbers of candidate passwords.
That changes the question. Instead of asking whether a password looks complicated, we need to ask how much uncertainty it presents to an attacker.
A well-designed password generator is useful precisely because humans are poor sources of randomness. We choose names, dates, keyboard patterns, familiar words, and substitutions that feel clever but are already represented in cracking rules.
Consider:
Michael1988!
It technically contains uppercase and lowercase letters, numbers, and a special character. Many password-strength policies would accept it. Yet it follows an extremely recognizable structure:
[Name] + [Year] + [Symbol]
A cracking system doesn’t need to exhaust the entire theoretical character space. It can prioritize exactly these structures.
From a cryptographic standpoint, password strength depends heavily on entropy—but entropy is frequently misunderstood. If a machine randomly selects 20 characters from a sufficiently large alphabet, each position introduces additional uncertainty. If a human selects 20 characters by combining a dog’s name, birthday, and favorite football club, the effective uncertainty can be dramatically smaller.
This is why length matters so much.
Suppose passwords are generated randomly from 94 printable ASCII characters. The theoretical search space for a 10-character password is:
94^10
At 16 characters:
94^16
At 20 characters:
94^20
Every additional genuinely random character multiplies the attacker’s workload. The important qualification is genuinely random. Adding predictable characters doesn’t provide the same benefit.
Summer2026!
is not equivalent, in practical cracking resistance, to a uniformly random 11-character string merely because both have 11 characters.
Attackers don’t search passwords alphabetically. Tools such as Hashcat and John the Ripper can apply sophisticated candidate-generation strategies. Wordlists derived from real breaches provide the base material. Rules then transform those words using common human habits.
A cracking process might try:
dragon
Dragon
dragon1
Dragon123
Dr@gon123
Dragon2026!
before wasting resources on arbitrary random strings.
This is one reason password composition rules sometimes create a false sense of security. Forcing one uppercase letter, one digit, and one symbol can improve very weak passwords, but users tend to satisfy those requirements predictably: uppercase at the beginning, digits near the end, punctuation last.
The resulting password complies with policy without necessarily being difficult to crack.
There is another distinction that matters: online guessing and offline cracking are completely different threat models.
During an online attack, the attacker submits login attempts to a real server. Rate limiting, CAPTCHA challenges, IP reputation systems, multi-factor authentication, and temporary account lockouts can dramatically reduce guessing speed.
If a service allows only a handful of attempts before introducing delays, brute-force attacks become expensive.
Offline cracking is more dangerous.
Suppose attackers compromise a database and obtain password hashes. They can attempt candidate passwords locally without interacting with the original service. Whether this becomes catastrophic depends heavily on how the service stored those passwords.
Passwords should never be stored as plaintext, and a general-purpose fast hash such as raw SHA-256 is not an appropriate password-storage mechanism.
Password hashing should deliberately be expensive.
Modern systems typically use password-oriented functions such as Argon2id, scrypt, bcrypt, or PBKDF2 with appropriately selected parameters. A unique random salt should also be generated for each password.
The salt doesn’t need to be secret. Its job is to prevent identical passwords from producing identical stored representations and to defeat precomputed rainbow-table attacks.
Conceptually:
stored_hash = KDF(password, unique_salt, cost_parameters)
Argon2id goes further by being memory-hard. An attacker can still test guesses, but each guess requires meaningful computational and memory resources. That makes large-scale GPU or specialized cracking substantially more expensive.
None of this means users should rely on server-side hashing to compensate for weak passwords. You usually don’t control how a website stores credentials.
The safer strategy is therefore to create passwords that remain difficult to guess even if their hashes are stolen.
For important accounts, I would generally prefer randomly generated passwords of around 16–20 characters or longer, assuming the service permits them. Twenty-four or more characters is perfectly reasonable when a password manager handles storage and entry.
For example, the architecture should look conceptually like:
random characters → password manager → unique account
rather than:
memorable base password → small modification → many accounts
Password reuse is arguably more dangerous than slightly insufficient password length.
Imagine you create an excellent 20-character password and use it on ten websites. One poorly secured website is breached. Your password is recovered or exposed.
Attackers don’t necessarily continue cracking anything. They simply test the same email/password combination against other services. This is credential stuffing, and it remains effective because password reuse is widespread.
Every account should therefore have a unique password.
This creates an obvious usability problem: humans cannot realistically memorize dozens or hundreds of independent high-entropy strings.
The practical solution is a reputable password manager.
The password manager changes the security architecture. Instead of remembering every credential, you protect an encrypted vault with one strong master password or passphrase. The manager generates unique random credentials for individual services.
Your master password deserves special treatment because it protects the vault.
A long passphrase can work well here. Randomly selected words are easier to type and remember than random character strings. But the words should actually be randomly selected rather than assembled into a meaningful quotation.
For example, the structure might be:
word-word-word-word-word
The security comes from randomly choosing the words from a sufficiently large list, not from inventing a grammatically sensible sentence.
Avoid famous quotations, song lyrics, movie lines, addresses, family information, birthdays, usernames, and other personally associated information. Attackers can incorporate OSINT into targeted password guessing.
Multi-factor authentication should then sit above the password layer.
A password answers roughly: What secret do you know?
A second factor introduces another requirement.
Authenticator applications using TOTP are generally preferable to SMS where stronger alternatives are available. Hardware security keys and passkeys based on public-key cryptography provide even stronger phishing resistance in supported environments.
This is especially important because a password can be cryptographically excellent and still be stolen through phishing.
Imagine entering a 30-character random password into a convincing fake login page. The attacker doesn’t need to crack it. You handed it over.
That is the limitation of discussing passwords purely in terms of entropy.
The complete threat model includes phishing, malware, compromised endpoints, password database breaches, credential stuffing, insecure recovery mechanisms, session-cookie theft, and social engineering.
There are also simple ways to test your configuration without exposing your real credentials.
Never paste an active password into random “password strength checker” websites.
Instead, test generated dummy passwords that follow the same construction method. For administrators, password-auditing tools can be used in authorized environments to evaluate how quickly different password policies fall to dictionary, rule-based, mask, and brute-force attacks.
The practical configuration is straightforward:
Unique password per account
+ high-entropy generation
+ sufficient length
+ password manager
+ MFA/passkey where available
For particularly sensitive accounts—primary email, banking, cloud administration, domain registrars, password-manager accounts—the recovery process deserves the same scrutiny. A 25-character password doesn’t help much if an attacker can reset it through a weak secondary email account.
The strongest password is therefore not the one that looks the strangest.
It is one generated from an unpredictable process, long enough to make exhaustive search impractical, unique to a single service, stored safely, and backed by additional authentication controls.
That’s the engineering distinction that matters.
Don’t try to outsmart password-cracking software with clever substitutions. Remove human predictability from the equation. Generate randomness, increase the search space, eliminate password reuse, and design the rest of the authentication chain so that compromising one layer does not automatically compromise the account.
