This article is intermediate level. It explains how password cracking works in enough detail that you can judge the risk to a system you run and choose controls for it. It deliberately contains no cracking tools, no configuration and no step-by-step guidance for breaking an account you do not own. To practise, use a deliberately vulnerable lab or a structured training platform under a written scope.

The core idea is not secret. A password system is only as strong as the cost of guessing the right value. Attackers rarely outsmart the maths; they pick the cheapest way in and try a very large number of candidates quickly. Knowing which of five methods applies to your system tells you which control matters.

What Password Cracking Actually Means

Cracking a password means finding the value that reproduces a stored match. The method depends on one fact: is the attacker working against a live login page, or against a copy of the password database?

Against a live login, each attempt costs a network round trip, and the system can rate-limit, lock the account or demand a second factor. Speed is limited by the target, so the attacker optimises for efficiency rather than volume. Against a stolen database the work is offline with no rate limiting, which is why a breach of hashes is far more serious than a failed login attempt.

Two terms are worth separating. Cracking is recovering the original password from a stored hash, a different problem from hashing, which is the protection. And guessing is what most intrusions involve, whether the candidates come from a wordlist, another site’s breach, or a pattern in your own behaviour.

Online Attacks Against Live Logins

These methods work against a running service, so they are bounded by the network and by rate limiting. They are still the most common route to a first foothold, because the target is a login form and the barrier is only as strong as that account’s password.

Dictionary attacks and wordlists

A dictionary attack tries candidates from an ordered list: the commonest passwords, dictionary words, popular team names, and lists leaked from earlier breaches. Those lists are freely available, which is why this cracking method is the first tried against almost every new target.

The defence is a blocklist check when the password is set, not a complexity rule. The NIST authenticator guidance is explicit that systems should reject passwords on a list of commonly used, expected or compromised values, and should not impose other composition rules.

Rule-based and mutation attacks

Once base words are ruled out, an attacker applies rules to them: append the current year, capitalise the first letter, add one digit, substitute letters for numbers, or append a name from the company website. The list is generated from guesses about your habits, which is why a password built from your employer and this year is a short password with extra steps.

This cracking method is defeated by unpredictability rather than punctuation. A passphrase of several unrelated words has no rule that produces it, and its length makes the rule set too large to enumerate.

Credential stuffing

Credential stuffing differs in kind. It takes real username and password pairs from a breach of another site and replays them against yours, assuming people reuse passwords. The OWASP credential stuffing prevention cheat sheet is the reference if you are building defences here.

Rate limiting alone struggles to detect it, because the traffic looks like many failed logins from many addresses rather than a flood from one. What stops it is multi-factor authentication, breached-password screening at sign-up, and device or session reputation checks, since stuffing usually succeeds where a cookie shows a returning user. The MITRE ATT&CK page for brute force sets out the wider family.

Brute Force Against Login Endpoints

Brute force in the strict sense tries every combination in the space: every string of a given length from a given character set. The space grows multiplicatively, so doubling the length while adding a character type multiplies the work enormously. A ten-character password from the full printable set is beyond practical cracking, which is why length beats composition.

Almost nobody attempts that space against a live system. Its real value is against a hash, offline, where parallelism and specialised hardware turn expensive cracking into routine work. The exceptions against live logins are short numeric codes, short PINs and unchanged defaults, where the space is small enough to exhaust.

Controls worth naming: rate limiting and progressive delays on repeated failures, monitoring for failures from many addresses, lockout designed so it cannot be abused, and a second factor. Our guide to online banking security covers this on a service where the asset is money.

Offline Password Cracking: Hashes, Salts and Peppers

With a copy of the password database, the attacker no longer touches your system. They take the stored hashes and test candidates locally at whatever speed their hardware allows. This is the most dangerous form of password cracking because nothing throttles it.

The protection is that a good password hash is deliberately slow and expensive to compute, and that each user’s hash is made unpredictable before storage.

Why salting and slow hashing change the arithmetic

A salt is a unique random value mixed into each user’s hash before storage. Two people with the same password get entirely different stored values, so a precomputed table of hashes cannot be reused across accounts, and a cracking run cannot be shared across users without repeating the expensive work for each.

A pepper is a secret kept outside the database, typically in configuration or a hardware facility, mixed in on top of the salt. Its value is that a stolen database alone is not enough. A slow hash adds a work factor deliberately, so each guess costs the attacker far more than it costs your server. The OWASP password storage cheat sheet is the working reference, and it recommends Argon2id because it resists both GPU-based and memory-based attacks, with scrypt as the fallback where Argon2 is unavailable.

Fast general-purpose hashes such as MD5 and SHA-1 are the opposite of what you want, because they were designed to be quick. A password hashed that way is effectively stored in a form recoverable in seconds on consumer hardware.

The Control That Stops Each Method

Method	What it does	Where it runs	Control that defeats it
Dictionary attack	Tries common passwords and leaked wordlists	Online or offline	Blocklist of common and breached passwords at the point of setting
Rule-based mutation	Applies patterns to likely base words	Online or offline	Long, unpredictable passphrases with no personal or date pattern
Credential stuffing	Replays username and password pairs from other breaches	Online	Multi-factor authentication, device reputation, breached-password screening
Brute force	Tries the whole character space, shortest first	Offline, or online against short codes	Long passwords or passphrases, rate limiting, lockout, second factor
Offline hash cracking	Tests candidates against stolen hashes at full speed	Offline	Argon2id or scrypt with a per-user salt and a high work factor

Length Beats Complexity: What Actually Raises the Cost

Complexity rules produce awkward, memorable passwords. Length produces boring, strong ones. The NIST guidance reflects this: no mandated mixtures of character types, no forced periodic changes, and a change only when there is evidence the credential has been compromised. The OWASP guidance on forgotten passwords matters too, because a reset flow that emails a new password or links to a predictable page undoes the strength you built in.

Three controls do most of the work. A password manager generates and stores long, unique passwords, removing both reuse and guessing. Multi-factor authentication removes the password as a single point of failure, so a successful cracking attempt leads nowhere. Breached-password screening at sign-up and login stops known-bad choices. Our guide to password security covers the setup for a household or small team.

One honest limit. No control is permanent. Assume a breach will happen and design so it is survivable: unique passwords so one site does not unlock another, a second factor so a recovered password grants nothing, and alerts so you find out. What happens next is covered in how the cyber attack chain works.

Frequently Asked Questions

How long should a password be?

Long enough that the cracking is not worth the cost. NIST guidance treats fifteen characters as the minimum for a password used on its own, and recommends that systems permit far more. A passphrase of several unrelated words is easier to remember than a short mangled word and far harder to guess.

Do I still need special characters?

They add value, but not the value old rules implied. Length contributes far more than character variety, and current NIST guidance advises against mandating mixtures of character types because the result is predictable passwords, which are easier to crack, rather than strong ones.

How often should I change my password?

Current guidance says do not change it on a schedule. Change it when you have reason to believe it has been exposed, when a service you use reports a breach, or when you find out you have been reusing it.

Does two-factor authentication make a weak password acceptable?

It makes a weak password far less consequential, which differs from making it strong. The second factor can still be phished, prompted or pushed, so a successful cracking attempt may not end the attack. Strong unique passwords plus a second factor is the combination worth having.

What is a pepper and do I need one?

A pepper is a secret value kept outside the password database and mixed into the hash. It means a stolen database on its own does not let an attacker verify guesses. Salting is the essential control; a pepper is a useful additional layer where the system is designed to support it.

Key Takeaways

• Password cracking against a live login is rate-limited; against a stolen hash database it is not.
• Dictionary and rule-based attacks exploit human habits, not cryptographic weakness.
• Credential stuffing succeeds through password reuse, so multi-factor authentication is the decisive control.
• Brute force is only practical against short codes, PINs and unchanged defaults.
• Per-user salts and slow hashes such as Argon2id are what make an offline cracking run expensive.
• Length beats character variety, and forced periodic changes usually make passwords weaker.
• Assume the breach happens: unique passwords, a second factor, and alerts you actually read.

For the practical setup that goes with all of this, read password security in 2026. If your concern is the wider path an attacker takes once one account falls, continue with the cyber attack chain explained.

Sources: NIST SP 800-63B, Digital Identity Guidelines, Authenticators; OWASP, Password Storage Cheat Sheet; OWASP, Credential Stuffing Prevention Cheat Sheet; OWASP, Forgot Password Cheat Sheet; MITRE ATT&CK, Brute Force technique T1110.