Brute force
In credential attacks, brute force is trying values until one works. Exhaustive search is the textbook definition and almost nobody does it: real attacks use wordlists, mutation rules and leaked material, so the practical question is never the size of the keyspace but how fast a guess can be tested.
How it works
Two settings, with completely different economics. Online, against a live service, each attempt is a request that can be counted, delayed, locked or logged, so the attacker is limited by the target and stays quiet. Offline, against recovered hashes, there is nothing to notice and nothing to slow the attacker except the algorithm that produced the hash, so the rate is a property of hardware and of the defender’s earlier design decision.
That decision is the whole game. A general purpose hash is fast by design, which is exactly the wrong property for a password, and a modern key derivation function is deliberately slow and memory-hard so that each guess costs real resources. A salt prevents one cracking run from covering many accounts at once; it does not slow anything down.
What goes wrong
Advice is still written for the exhaustive model. Complexity requirements that demand a capital letter, a digit and a symbol produce predictable transformations of a dictionary word, and the rule engines in cracking tools model those transformations directly, so the rule that was meant to expand the search space narrows it. Length and unpredictability change the outcome; character classes largely do not.
The second problem is defending in the wrong place. Lockout after five attempts stops a single account being hammered and does nothing against password spraying, which sends one password to ten thousand accounts and never reaches five on any of them, or against credential stuffing, which arrives with a correct password on the first attempt. Aggressive lockout also becomes a denial of service an attacker can trigger deliberately.
Third, the offline case is decided long before the attack. Once we hold a hash, no policy applies. Only the algorithm, its parameters and the length of the password matter.
Where this shows up in an audit
On an internal test we do not estimate password strength, we measure it: recover the hashes with the client’s agreement, run them under controlled conditions, and report the percentage recovered, the patterns that appeared and how many belonged to privileged accounts. Recovered passwords never appear in the report body. The finding is written against the hashing choice and the accounts, and the most useful number is normally how many privileged accounts fell in the first hour. This is part of how password strength is actually measured on an internal test.