How brute‑force attacks work
Why length matters: example calculations and mitigation strategies.
In brute‑force attacks, attackers try to guess a password by systematically trying all possible character combinations. The underlying idea is simple: test as many combinations per second as possible – ideally on GPUs or in distributed systems. This is also referred to as an exhaustive search (exhaustive search).
In practice, such attacks are unfortunately often successful because many passwords are too short, limited to only a few character sets (letters only), or appear in word lists. This drastically reduces the search space and makes guessing easier. More importantly, we distinguish between online attacks (against login forms, where rate limiting/account lockouts help) and offline attacks (against stolen password hashes, where the hash function and password strength determine the attack time).
Cracking passwords (offline) ≠ “decrypting” them
Passwords are not decrypted; they are stored as hash values and then searched using guessing + hashing (brute force, dictionary/mask attacks). The computational throughput of modern hardware is in the billions per second (for fast hash functions), which is why long passwords hashed with slow algorithms (e. g. Argon2, scrypt, PBKDF2, bcrypt) are crucial.
Password combinations and length
The following examples illustrate the impact of length and character set. For illustration, we assume 2 billion attempts per second (very powerful single machine; real‑world values vary significantly depending on hardware and – in the offline case – the hash function).
Typical character groups:
- Digits (10: 0–9)
- Letters (52: A–Z and a–z)
- Special characters (≈ 32; depends on the character set allowed by the service)
The number of possible combinations is given by:
Possible combinations = (character set size)password length
Important: The table shows the maximum search time. On average, the actual time is about half of that. In addition, dictionary, rule‑based and mask attacks significantly reduce the search space, while slow password‑hashing algorithms drastically reduce the effective rate.
| Password consists of | Possible combinations (formula) | Required time (at 2 bn/s) |
|---|---|---|
|
5 characters |
(
53
) × 263 × 102 = |
17.576.000 / 2.000.000.000 = |
|
7 characters |
(
71
) × 261+6 = |
56.222.671.232 / 2.000.000.000 = |
|
8 characters |
(
84
) × (
42
) × 264 × 322 × 102 = |
19.653.623.808.000 / 2.000.000.000 = |
|
9 characters |
(
92
) × (
73
) × (
42
) × 262+3 × 102 × 322 = |
9.197.895.942.144.000 / 2.000.000.000 = |
|
12 characters |
(
123
) × (
94
) × (
53
) × 263+4 × 323 × 102 = |
7.295.525.784.083.496.960.000 / 2.000.000.000 = |
|
14 characters |
(
144
) × (
104
) × (
63
) × 264+4 × 103 × 323 = |
28.768.690.008.569.256.345.600.000 / 2.000.000.000 = |
Conclusion: every additional character multiplies the search space. Length beats complexity rules – especially against offline attacks – provided that services use appropriate, slow hashing algorithms with salt.
Protection against brute‑force attacks
The most effective user‑side measure is a long, random master password or a passphrase (e. g. several random words) – unique per service. Password Depot supports secure generation and shows an estimated attack time that takes into account not only length/character set but also dictionary weaknesses.
- Enable MFA/2FA (e. g. TOTP app or hardware token) – where possible, passkeys are even better. See BSI guidance.
- No password recycling. Every account requires its own strong password.
- Length instead of forced complexity. Services should allow long passwords/passphrases (at least 64 characters), accept paste, and enforce blacklists of compromised/common passwords instead of arbitrary complexity rules.
- Slow hashing algorithms such as Argon2, scrypt, PBKDF2 or bcrypt – with salt and configurable work factors. For long, random passwords this makes offline brute‑force attacks economically unattractive.
- Rate limiting/throttling & lockouts: limit login attempts, introduce increasing delays and temporary account lockouts after multiple failures. Automated bots can also be slowed down by CAPTCHA.
In addition, Password Depot makes online rate attempts more difficult by briefly locking the master‑password input form after incorrect entries – with increasing waiting time for repeated failed attempts.
Further resources
- NIST SP 800‑63B (Rev. 4), Appendix: Strength of Passwords – length, passphrases, offline attacks (billions of hashes/second) and rate‑limiting concepts.
- NIST SP 800‑63B (Rev. 3) – among other things: minimum length, allowing long passwords (≥ 64), blacklists, allowing paste; rate limiting/throttling with a cap of max. 100 consecutive failed attempts.
- OWASP Password Storage Cheat Sheet – recommended algorithms (Argon2, scrypt, PBKDF2, bcrypt), salt/work‑factor guidance.
- OWASP Authentication Cheat Sheet – guidelines on password input, length, blacklists and protection mechanisms.
- BSI: Creating secure passwords – including long/complex passwords and passphrases; practical tips.
- BSI press release 31.01.2025 – no enforced regular password changes; prefer 2FA/passkeys.
- distributed.net RC5 / current proxy status – illustrative example of exhaustive search and distributed compute power.