Brute Force Attack
A Brute Force Attack is where software systematically generates rapid-fire input trying to guess the correct value of a password. It is a trial-and-error approach which can be used when decryption would be difficult. It is also known as an “exhaustive key search” because it searches by trying all of the keys.
The total time required for trying all of the keys depends on two main variables: the size of the search key space and the speed of each attempt.
Imagine a combination lock with three-wheels, each of which can be set to numbers 0 to 9. Ten numbers on three wheels provides 1,000 combinations (10^3). A Brute Force Attack might try “000”, “001”, “002”, “003”, and continue until it reached “999” or found the correct combination. If each attempt takes one second, then it will take 16.7 minutes to try all keys.
The time required to search the total key space can be described with an equation.
(Possibilities count ^ Key length) x Time per attempt
It is important to note that this is not the same as the actual time required to find the correct key. The key could be the first guess, or the very last guess, or most likely somewhere in the middle. But calculating the maximum time is useful because it provides a relative measurement of the strength of a key or password.
Search Key Space
The possibilities count and key length are the parameters which define the search key space. As these values increase, the time it takes to perform a Brute Force Attack increases, sometimes exponentially.
Time Per Attempt
The time per attempt is a parameter of the mechanism performing the search. For a combination lock, that is how fast can your fingers try each number. For passwords, it is a function of how fast a computer and software can try each password and how fast the software and algorithm responds to an attempt.
As compute capacity grows—driven primarily by GPUs, ASICs, and cloud-scale parallelism rather than raw single-core CPU speed—attempts can be submitted faster and the total Brute Force time decreases. More attempts can be performed per minute when many computers work on the solution in parallel, such as with distributed computing or a botnet.
Calculations can also be performed faster if a GPU (Graphics Processing Unit) can be used instead of a CPU. GPUs are specialized processors which are designed for calculation speed. They are frequently used in password cracking computers. CPUs can make millions of guesses per second, while GPUs can make billions of guesses per second. Incidentally, bcrypt’s small working set (~4 KB) and sequential Blowfish key schedule limit GPU parallelization somewhat, but bcrypt is not memory-hard. Memory-hard algorithms like scrypt and Argon2id are specifically designed to resist GPU and ASIC acceleration by requiring large amounts of RAM (tens to hundreds of MB) per guess.
Another important factor is how fast the login system responds to each attempt. In an ideal scenario, password cracking software has the encrypted hash to compare with each of its attempts. This allows it to try millions of guesses per second. A hash like bcrypt has a “cost” parameter which causes the algorithm itself to slow down calculation speeds from millions of guesses to less than 200.
However, if the encrypted hash is not known, then a Brute Force attack must make each attempt through the login software which is much slower. A typical web application which has to query the database will take 0.5-1.5 seconds to respond.
Preventions
The first defense against a Brute Force attack is to choose a strong encryption algorithm. MD5 and SHA-1 are not recommended because they have collisions and are vulnerable to Rainbow Tables. Argon2id is the current OWASP-recommended algorithm for password hashing; bcrypt is a solid fallback and is slow by design. Argon2id adds a tunable memory cost (making it memory-hard and expensive for GPU/ASIC attacks), while bcrypt’s sequential Blowfish key schedule limits GPU parallelization. Both can be slowed further by increasing their cost/iteration parameters.
The next defense is to get users to pick strong passwords. Most importantly, you should require that users choose longer passwords — current NIST SP 800-63B Rev. 4 guidance is a minimum of 15 characters when password is the only authenticator, and verifiers should accept up to at least 64 characters. Remember, longer passwords exponentially increase the key space which must be searched. And by all means, never impose a short maximum length. With a modern password-hashing algorithm like Argon2id, the hash function does not care about the input length and can hash arbitrary-sized data while still returning a fixed-length digest. Note that bcrypt is the exception — most bcrypt implementations silently truncate the password at 72 bytes (a property of the underlying algorithm), so if you are still using bcrypt either cap the input at 72 bytes or pre-hash long inputs as described in the OWASP Password Storage Cheat Sheet; Argon2id avoids this constraint entirely. Do not impose character-composition rules (requiring a mix of uppercase, lowercase, digits, and symbols); NIST SP 800-63B Rev. 4 explicitly forbids them because they push users toward predictable patterns. Instead, accept all printable ASCII and Unicode characters, screen submitted passwords against a blocklist of breached/common passwords, and display a password strength meter to encourage longer passphrases. See Strong Passwords for details. Educate users in an organization about the importance of choosing strong passwords and not re-using them for other sites.
It is a good idea to encourage (or even require) that a password contains no dictionary words. Maintain a list of common passwords, like “letmein”, and reject passwords if they are on the list.
Use login throttling to slow down the rate of failed attempts.