Secure Passwords: Why Length Matters More Than Complexity

We think we're doing the right thing by adding uppercase letters and symbols. In reality, a longer password - even one made up entirely of letters - is mathematically more secure. Here's why, what length to aim for, and how to create a truly secure password.

Is a long password better than a complex one?

Length beats complexity. It's counterintuitive, but the numbers are clear.

Let's compare three passwords:

• 8 characters, lowercase only (26 possibilities per position): 26⁸, or roughly 208 billion combinations
• 8 characters, all types combined - lowercase, uppercase, digits, and symbols (95 possibilities per position): 95⁸, or roughly 6.6 trillion combinations
• 16 characters, lowercase only: 26¹⁶, or roughly 43 billion billion combinations

The third one - the simplest looking of the three - is incomparably more resistant than the other two. Each additional character multiplies the possibility space exponentially, whereas adding character types produces only a linear gain.

What length makes a password secure?

Aim for at least 12 characters for everyday use, and 16 or more for sensitive accounts: your primary email, banking, and password manager. Below 12 characters, a password becomes vulnerable to an offline attack on a stolen database.

The reason goes back to the calculation above: it's the extra characters, far more than the types of characters, that drive up the number of combinations. A 16-character lowercase password is already beyond the reach of a brute-force attack. There's no need to chase complicated rules - go longer, not more complex.

How do you create a secure password, with an example?

The right method depends on the use case. For passwords you need to remember - your password manager master password, your login session - use a passphrase: a string of random words that is both long and memorable. For everything else, let a generator produce a random password you won't need to memorize.

Here's what that looks like in practice:

• A passphrase: "sardine galaxy tambourine velvet pirate" (five randomly chosen words, easy to memorize, very hard to crack)
• A generated password: "GD€75€!RPF]HT" (random, stored in the password manager, never typed from memory)

And what to avoid:

• A dictionary word, a first name, or a date: "Julian2024", "Password!"
• A "clever" substitution: "P@ssw0rd" (see the next section)
• Reusing the same password across multiple sites

One important note: these examples are for illustration only. Never reuse them - a password published anywhere is no longer secret. The ideal approach is to let a generator handle the randomness for you, since the human brain simply can't do it. Octopussian's password manager includes exactly that kind of generator.

Why doesn't replacing letters with symbols actually help?

Substituting "a" with "@", "o" with "0", or "e" with "3" is a false sense of security. These substitutions have been known for decades and are built into every modern cracking tool. "P@ssw0rd" is not significantly more resistant than "password" against an automated attack.

This habit creates an unjustified feeling of security. It stems from the earliest computer security recommendations, from a time when attack tools were far less sophisticated. Today, a genuinely long and random password is far better than a short one dressed up with symbols.

What is a passphrase and why is it effective?

A passphrase is a sequence of random words used as a password - for example, "horse battery staple mountain cactus." It is long, robust, and memorable all at once.

The entropy of a 5- to 6-word passphrase drawn from a dictionary of 7,776 entries (the Diceware method) is comparable to that of a random 10- to 12-character password. Memorability, on the other hand, is incomparably easier.

A passphrase is especially well suited as the master password for a password manager - the only one you truly need to remember. For everything else, a generator is preferable: it produces cryptographically random output without human bias, something the human brain simply cannot do. We go into detail in a dedicated guide on how to build a strong passphrase and how many words to aim for.

Should you change your password regularly?

No. Periodic password changes have been officially discouraged since 2017 by NIST, the U.S. standards body for cybersecurity.

This goes back a long way. In 2003, Bill Burr, then a NIST employee, authored publication SP 800-63, which became a global reference. It recommended mandatory complexity and password changes every 90 days. In 2017, after retiring, he publicly acknowledged that those recommendations were based on 1980s assumptions with no solid empirical backing.

The problem with forced rotation is concrete: it pushes users toward predictable variations - "January2024", "January2024!", "February2024!". That's exactly the pattern attackers test first.

A good password has no expiration date. Change it only if a compromise is confirmed or suspected.

Why should you never reuse a password?

Because billions of username/password pairs from data breaches are freely circulating. Attackers automatically test them across dozens of services - this is known as credential stuffing.

If you use the same password for your email and a forum that was breached three years ago, your email account is potentially compromised. And email is often the master key to everything else: it's the channel through which "forgot your password" links for all your other accounts flow.

The only defense: one unique password per service, no exceptions. This is what makes a password manager essential in practice - no one can memorize dozens of long, random passwords.

Services like Have I Been Pwned (haveibeenpwned.com) let you check whether an email address or password appears in a known compromised database. It's an objective way to decide when to change a password, without waiting for an arbitrary rotation schedule.

Is a strong password enough to stay protected?

No. Several attack vectors make the intrinsic quality of your password irrelevant.

Shoulder surfing - someone glancing at your screen in an open office or on public transit - is underestimated because it doesn't look like a cyberattack. A keylogger, whether hardware or software, captures your password before it even reaches the server. And phishing tricks users into entering their password on a fraudulent site themselves: in that case, length and complexity are completely beside the point.

These realities make the case for a layered approach: a strong password is necessary but not sufficient. Two-factor authentication, vigilance against phishing, and - where the service supports it - passkeys round out the picture.

What is the difference between an online and an offline attack?

This is a fundamental distinction that radically changes the level of security required.

In an offline attack, the attacker has obtained a copy of the database - through a breach or backup theft. They work locally, with no external limitations. With a modern GPU, they can test several billion combinations per second against an MD5 hash, or several hundred million against bcrypt. Only the password length and the quality of the hashing algorithm make a difference.

In an online attack, every attempt goes through the network and the server. Defense mechanisms change the equation: progressive delays between attempts, temporary lockouts after multiple failures, CAPTCHAs, suspicious IP detection. With just a one-second delay between tries, a 10-character password becomes practically unbreakable.

A properly protected online service can tolerate a reasonably shorter password than a file that could be exfiltrated and attacked offline.

How does a server protect stored passwords?

In the event of a database breach, the hashing algorithm determines how well passwords hold up. Not all algorithms are equal.

MD5 and SHA-1 are obsolete: they can be cracked at billions of attempts per second. Bcrypt, designed to be deliberately slow, remains a proven standard with an adjustable cost factor. Argon2, winner of the Password Hashing Competition in 2015, is today's recommendation: it resists attacks using GPUs and specialized hardware (ASICs).

Salting completes the picture: by adding a unique value to each password before hashing, it ensures that two users with the same password produce different hashes. This neutralizes rainbow table attacks.

Why do some sites impose absurd password rules?

Because their systems don't handle passwords correctly on the server side. A maximum length of 10 or 12 characters, restrictions on certain special characters, or refusals of certain combinations "for security reasons" often reveal a password stored in plaintext or poorly hashed.

A properly hashed password - using bcrypt or Argon2 - has no reason to have a length limit. If a service prevents you from using a long, random password, that's a red flag about the overall quality of its security.

Why is password security a collective concern within a company?

Because a single compromised account can expose an entire shared workspace: colleagues' data, customer data, and the company's reputation.

An employee who secures their access to a task-tracking tool poorly may think the stakes are low. But that tool likely contains specifications, client communications, and information about internal architecture. An attacker who gets in through that door can move laterally toward far more sensitive targets.

Password security within a team is a shared responsibility. That's what justifies administrative features in a password manager: enforcing minimum rules, verifying that every team member has enabled two-factor authentication, and being able to revoke access quickly without depending on individual goodwill.

Key takeaways

• Prioritize length over complexity: 16 lowercase characters are stronger than 8 characters of mixed types.
• Aim for at least 12 characters, and 16 or more for sensitive accounts.
• Use a passphrase for what you need to remember, a generator for everything else.
• Don't change passwords out of habit: NIST has officially discouraged this since 2017.
• One unique password per service: credential stuffing exploits reuse at scale.
• In a team setting, this is a collective concern: one weak account puts everyone at risk.