Learn how brute-force and dictionary attacks select password guesses, why human password habits matter, and how slow password hashing raises attack costs.
Brute-force and dictionary attacks both test password candidates, but they choose those candidates differently. A pure brute-force search explores combinations from a defined character set. A dictionary attack starts with likely passwords and modifies them using human patterns. In real incidents, attackers often combine dictionaries, rules, masks, leaked credentials, and probabilistic models rather than choosing one method.
A brute-force attack systematically tries every candidate within its search space. For example, all eight-character lowercase strings form 26 to the power of eight possibilities. Adding uppercase letters, digits, symbols, and more length causes the space to grow rapidly.
That growth protects long, randomly generated passwords. It does less for predictable human choices because attackers do not need to search every possible string in order. They prioritize what people are likely to choose.
A dictionary is not limited to words from a printed language dictionary. It can include breached passwords, names, keyboard patterns, song titles, dates, brands, sports teams, and organization-specific terms. Rules then transform entries: capitalize the first letter, replace “a” with “@,” append a year, duplicate a word, or add punctuation.
Passwords such as CompanyName2026! may satisfy a complexity rule while remaining early candidates in a targeted attack. Predictability matters more than the number of character categories displayed by the password form.
The attacker submits candidates to the live login endpoint. Rate limits, account lockouts, multifactor authentication, bot detection, and monitoring can slow or stop the attempt. Excessively strict lockouts can be abused to deny service, so controls should consider account and network behavior together.
The attacker has stolen password verifiers and tests candidates on their own hardware. Application rate limits no longer apply. The cost of the password-hashing function becomes critical. MD5 and plain SHA-256 permit cheap guesses, while Argon2id, scrypt, bcrypt, and PBKDF2 are designed to raise the cost.
A ten-character password does not have one fixed cracking time. The answer depends on how it was chosen, the candidate strategy, hardware, algorithm, parameters, salt, and attacker budget. Marketing charts that give one universal time for each length hide these variables.
Fast hashes were designed for checksums and protocol operations. Using MD5 for passwords gives attackers far more guesses per second than a tuned password-hashing function. For the underlying design problem, see why MD5 should never store passwords.
Credential stuffing does not crack the target site’s hash. Attackers take username and password pairs exposed by another service and try them on new sites. Password reuse makes this effective even when the target stores its own passwords correctly.
Defenses include multifactor authentication, breached-password screening, login anomaly detection, device and network signals, and user alerts. Password hashing protects a stolen database; it does not stop users from submitting a password already known to attackers.
This ordering is why forcing a symbol and a number can produce weak passwords with compliant formatting. A longer passphrase made of unrelated words or a randomly generated password from a password manager is usually harder to predict.
Use a unique random salt and a current password-hashing function. Tune the cost on production-class hardware and store the complete encoded record. Rehash after successful login when settings become outdated. Do not reduce protection for all users because one old device has poor performance without assessing alternatives.
Limit access to password tables and backups, monitor unusual exports, protect administrative paths, and separate optional pepper secrets from the database. A hash breach should trigger a documented response, including resets based on risk and notification requirements.
Rate-limit by more than IP address because attackers distribute traffic. Consider account, device, network, geography, and behavior. Add small progressive delays, require stronger checks for suspicious attempts, and avoid revealing whether an account exists.
Offer multifactor methods that resist phishing where the risk justifies them. Protect reset and recovery flows to the same standard as login. A strong password is irrelevant if an attacker can reset it through a weak support process.
Use a password manager to generate a unique random password for every service. When memorization is required, favor length and unpredictability over forced substitutions. Do not reuse a strong password across sites. Enable multifactor authentication and protect the email account used for recovery.
Organizations may assess password quality using controlled, authorized processes after a migration or incident. Do not move production hashes into unmanaged cracking tools or personal devices. Define scope, handling, deletion, access, and reporting before testing. Avoid publishing examples that reveal employee patterns.
Brute force explores a space; dictionary attacks exploit probability. Modern attackers mix both, then add data from breaches and the target organization. Defenders should avoid simplistic password rules and focus on unique passwords, costly salted hashing, layered online controls, secure recovery, and monitoring. The goal is to reduce both the number of useful guesses and the rate at which attackers can test them.