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
(3 lowercase letters,
2 digits)

( 53 ) × 263 × 102 =
17.576.000

17.576.000 / 2.000.000.000 =
0.008788 seconds

7 characters
(1 uppercase letter,
6 lowercase letters)

( 71 ) × 261+6 =
56.222.671.232

56.222.671.232 / 2.000.000.000 =
28.111335616 seconds

8 characters
(4 lowercase letters,
2 special characters,
2 digits)

( 84 ) × ( 42 ) × 264 × 322 × 102 =
19.653.623.808.000

19.653.623.808.000 / 2.000.000.000 =
9.826,811904 seconds =
≈ 2.73 hours

9 characters
(2 uppercase letters,
3 lowercase letters,
2 digits,
2 special characters)

( 92 ) × ( 73 ) × ( 42 ) × 262+3 × 102 × 322 =
9.197.895.942.144.000

9.197.895.942.144.000 / 2.000.000.000 =
4.598.947,971072 seconds =
≈ 53.23 days

12 characters
(3 uppercase letters,
4 lowercase letters,
3 special characters,
2 digits)

( 123 ) × ( 94 ) × ( 53 ) × 263+4 × 323 × 102 =
7.295.525.784.083.496.960.000

7.295.525.784.083.496.960.000 / 2.000.000.000 =
3.647.762.892.041,74848 seconds =
≈ 115,590.63 years

14 characters
(4 uppercase letters,
4 lowercase letters,
3 digits,
3 special characters)

( 144 ) × ( 104 ) × ( 63 ) × 264+4 × 103 × 323 =
28.768.690.008.569.256.345.600.000

28.768.690.008.569.256.345.600.000 / 2.000.000.000 =
14.384.345.004.284.628,1728 seconds =
≈ 455,812,387.64 years

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