How brute-force attacks work
Why length matters: calculation examples and countermeasures.
In brute-force attacks attackers try to guess a password by systematically trying every possible character combination. 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, are limited to only a few character sets (letters only), or appear in wordlists. This drastically reduces the search space and makes guessing easier. Even more importantly, a distinction is made 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 time required for the attack).
Cracking passwords (offline) ≠ "decrypting"
Passwords are not decrypted, but stored as hash values and then searched using guessing + hashing (brute force, dictionary/mask attacks). The computing speed of modern hardware is in the billions per second range (for fast hash algorithms), which is why long passwords hashed with slow algorithms (e.g. Argon2, scrypt, PBKDF2, bcrypt) are crucial.
Historical and current context: The RC5 project by distributed.net demonstrates the raw power of exhaustive search across a keyspace: 56-bit was solved in 1997 after 250 days, 64-bit in 2002 after 1,757 days. Currently, the proxy status for RC5-72 approx. 2.38 trillion keys per second (as of today). This is key brute force and not password hashing, but it illustrates how effectively distributed computing power scales.
Password composition and length
The following examples show the impact of length and character selection. For illustration, a rate of 2 billion attempts per second is assumed (a very powerful single machine; actual values vary widely depending on hardware and, in offline scenarios, the hashing algorithm).
Typical character groups:
- Digits (10: 0-9)
- Letters (52: A-Z and a-z)
- Special characters (≈ 32; depends on the service's allowed character set)
The number of possible combinations is calculated as follows:
Important: The table shows the maximum search time. On average, the actual time is about half 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) | Time required (at 2 bn/s) |
|---|---|---|
| 5 characters 3 lowercase, 2 digits | (53) × 263 × 10217,576,000 | 0.009 seconds |
| 7 characters 1 uppercase, 6 lowercase | (71) × 261+656,222,671,232 | ≈ 28 seconds |
| 8 characters 4 lowercase, 2 special, 2 digits | (84) × (42) × 264 × 322 × 10219,653,623,808,000 | ≈ 2.73 hours |
| 9 characters 2 uppercase, 3 lowercase, 2 digits, 2 special | (92) × (73) × (42) × 262+3 × 102 × 3229,197,895,942,144,000 | ≈ 53 days |
| 12 characters 3 uppercase, 4 lowercase, 3 special, 2 digits | (123) × (94) × (53) × 263+4 × 323 × 1027.30 × 1021 | ≈ 115,591 years |
| 14 characters 4 uppercase, 4 lowercase, 3 digits, 3 special | (144) × (104) × (63) × 264+4 × 103 × 3232.88 × 1025 | ≈ 455,812,388 years |
Conclusion: Each additional character multiplies the search space. Length beats complexity rules, especially against Offline attacks – provided services use suitable, 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 to each service. Password Depot helps generate them and displays an estimated time to crack that takes dictionary weaknesses into account in addition to length/character set.
- Enable MFA/2FA (e.g. TOTP app or hardware token) – where possible, passkeys are even better. See BSI guidance.
- Do not reuse passwords. Every account needs its own strong password.
- Prioritize length over mandatory complexity. Services should allow long passwords/passphrases (min. 64 characters) and block compromised passwords (blacklist).
- Slow hashing algorithms on the server side (e.g. Argon2, scrypt, PBKDF2, bcrypt) with salt and appropriate work factors; fast hashes such as MD5/SHA-1 are unsuitable for password storage.
- Rate limiting/throttling & lockouts: Online attacks must be slowed down through limited failed attempts, progressive delays, and, if necessary, CAPTCHA.
In addition, Password Depot makes online rate attempts more difficult by briefly locking the master password input field after incorrect entries – with increasing wait times for repeated failed attempts.
Practical guidance for service providers (technical teams)
- Accept all printable characters, including spaces/Unicode, and allow copy & paste.
- Implement blocklists (compromised/common passwords) and rate limiting with clear user guidance.
- Store passwords only as salted, hashed values using slow KDFs and review work factors regularly.
Further resources
- NIST SP 800–63B (Rev. 4), Appendix: Strength of Passwords – length, passphrases, offline attacks (billions of hashes/sec) and the rate-limiting concept.
- NIST SP 800–63B (Rev. 3) – including minimum length, allowing long passwords (≥ 64), blacklists, allowing paste; Rate-Limiting/Throttling with a limit of max. 100 consecutive failed attempts.
- OWASP Password Storage Cheat Sheet – suitable methods (Argon2, scrypt, PBKDF2, bcrypt), salt/work factors.
- OWASP Authentication Cheat Sheet – guidelines on password entry, length, blacklists, and lockout mechanisms.
- BSI: Creating secure passwords – including long/complex passwords and passphrases; practical tips.
- BSI Press 31/01/2025 – no enforced regular password changes; prefer 2FA/passkeys.
- distributed.net RC5 / current proxy status – illustrative example of exhaustive search and distributed computing power.
Creating secure passwords
Learn how to create passwords that can withstand brute-force attacks.
Tips for secure passwords