Warum P@ssword1 nicht wirklich sicher ist

The password policy at most companies goes something like this: minimum 8 characters, at least one uppercase, one lowercase, one number, one special character. And somewhere, an IT manager thinks this is securing things.

Meanwhile, “Password1!” clears every single one of those requirements. So does “P@ssw0rd1”. And “Summer2024!”. These all show up regularly in breach databases — not in spite of complexity rules, but partly because of them.

Why Complexity Rules Backfire

When you force people to add a capital letter, a number, and a symbol, they don’t create randomness — they follow patterns. Capitalize the first letter. Swap ‘a’ for ‘@’ and ‘o’ for ‘0’. End with ‘1!’ or the current year. Every password-cracking ruleset includes these transformations. Running “dictionary + common substitutions + append numbers/symbols” against a leaked hash database is a standard attack, and it works because that’s exactly what the policy trained people to do.

The complexity requirement gives the illusion of security while systematically guiding users toward predictable patterns. It’s security theatre with extra steps.

Entropy: The Thing That Actually Matters

Password strength comes down to entropy — a measure of unpredictability. The formula is straightforward:

H = L × log₂(N)

Wo L is the password length and N is the size of the character set being drawn from. More bits = more guesses required = harder to crack.

The critical word is drawn from. This formula assumes each character is selected randomly from N possibilities. The moment a human picks the characters, all bets are off — because humans are predictably bad at being random.

The Numbers

Here’s how common password strategies actually compare:

“correct horse battery staple” and “P@ssw0rd” have similar theoretical entropy on paper — but only the passphrase actually achieves it, because a dice roll is genuinely random and “password with o→0 and a→@” is not. Attackers know every substitution rule you know.

What NIST Figured Out in 2017

NIST Special Publication 800-63B quietly reversed decades of conventional wisdom. The key changes from the 2017 revision:

• No mandatory complexity rules. Requiring uppercase/lowercase/numbers/symbols doesn’t improve security the way everyone assumed.
• No forced periodic rotation. “Change your password every 90 days” produces Password1 → Password2 → Password3. Unless there’s evidence of compromise, rotation does more harm than good.
• Length over complexity. A longer password is almost always more secure than a shorter complex one. NIST recommends a minimum of 8 characters and suggests allowing up to at least 64.
• Screen against known breached passwords. Block passwords that appear in known breach databases. That’s far more effective than requiring a special character.

Most enterprise IT departments are running 2003 policies in 2025. The guidance changed. The password dialogs haven’t.

Passphrases vs “Complex” Passwords

The xkcd comic “correct horse battery staple” wasn’t just a joke — the math holds up. A passphrase made of four genuinely random common words has around 44–52 bits of entropy depending on the word list. That beats most “complex” passwords people actually create in practice, and it’s something a human can actually remember and type.

The catch: the words have to be genuinely random. “My dog Max loves pizza” is not a passphrase — it’s a sentence with personal context that reduces the search space significantly. Pick words using dice (Diceware) or a proper random number generator, not your brain.

Common Password Security Myths

• Myth: Special characters make passwords secure. Only if the underlying password is random. Appending “!” to a word-based password adds maybe 6 bits of entropy and almost nothing in a rules-based attack.
• Myth: Longer passwords are harder to type, so they’re worse UX. A four-word passphrase is longer in characters but often easier to type than Tr0ub4dor&3.
• Myth: Frequent rotation equals better security. Breach datasets consistently show that forced rotation leads to predictable incremental changes. NIST now explicitly recommends against it except on confirmed compromise.
• Myth: A password manager is risky because one breach exposes everything. The alternative — reusing weak passwords across sites — exposes everything on the first breach of any service you use. Password managers win on expected value.

What Actually Works

Use a password manager and let it generate long, truly random passwords (16+ characters, full character set). You remember one strong master password; the manager handles everything else. Bitwarden, 1Password, and KeePassXC are the reasonable choices depending on whether you want cloud sync or local-only.

Use Diceware passphrases for anything you need to type or remember. Roll actual dice, look up the words in the EFF large word list, string four or five together. Don’t skip the dice — picking words yourself defeats the point entirely.

You can check where a password actually lands on the entropy scale with the Password Strength Analyzer — it shows real estimated crack time rather than the green/yellow/red theatre most sites offer. And if you need a properly random password generated for you, the Passwortgenerator lets you set length and character set and produces something that isn’t “Summer2025!”.

The Actual Takeaway

The complexity rules won. They’re baked into every enterprise policy, every consumer account signup, every “your password must contain…” dialog. They also failed — breach databases are full of exactly the kinds of passwords those rules produce.

Length and genuine randomness are the levers that actually move entropy. Everything else is a checkbox that makes a password dialog look like it’s doing something.

Das könnte Ihnen auch gefallen

Neu

TOML vs YAML vs JSON – Konfigurationsformate nach dem Grad, in dem sie Sie nerven

Mehr lesen "

Aktualisiert am 5. Juni 2026

Neu

GraphQL-Schemata: Schreiben, Formatieren und Verstehen von SDL ohne Boilerplate

Mehr lesen "

Aktualisiert am 5. Juni 2026

Neu

HEX vs RGB vs HSL vs OKLCH – In welchen Situationen jeder CSS-Farbbereich sinnvoll ist

Mehr lesen "

Aktualisiert am 5. Juni 2026

Neu

HTTP-Cache-Header: Cache-Control, ETag und max-age ohne Vermutung

Mehr lesen "

Aktualisiert am 4. Juni 2026