Attackers do not usually “decrypt” a password. They obtain it through phishing or malware, reuse credentials leaked elsewhere, guess against a live login, or steal password hashes and test guesses offline. Each path has different speed limits and different defenses.
Four attacks people call “password cracking”
Online guessing
The attacker submits guesses to a real login page or protocol. The service can observe and slow the attempts, block suspicious sources, require additional verification, and alert the user.
A classic brute-force attack tries many candidates against one account. Password spraying reverses the pattern: it tries a small number of common passwords across many accounts, hoping to stay below per-account lockout thresholds.
Credential stuffing
An attacker takes username-password pairs exposed by one service and tests them on others. No sophisticated cracking is required if users reused the same password. This is why uniqueness is a stronger defense than regularly turning Summer2025! into Autumn2026!.
Phishing and theft
A fake login page can collect the exact password, and some phishing proxies can relay sessions or one-time codes in real time. Malware, browser extensions, information stealers, and exposed logs can steal credentials directly.
Phishing-resistant passkeys or security keys help because the credential is scoped to the legitimate service. Endpoint security and secure session handling still matter.
Offline hash cracking
Responsible services do not store plaintext passwords. They store outputs from a password-hashing function along with parameters and a unique salt. After stealing that database, an attacker can calculate candidate hashes on their own hardware and compare results. The service cannot rate-limit an offline attacker.
The attacker is not reversing the hash. They are asking repeatedly, “Does the hash of this guess, with this salt and these parameters, match?” Human password patterns make candidate selection far more efficient than blindly trying every possible string.
Why salts matter
A unique random salt is stored with each password hash. It prevents identical passwords from producing identical stored values and defeats useful precomputation across many accounts. Salts do not need to be secret.
Salting does not make a weak password strong. It forces the attacker to work on each hash separately, which is extremely valuable at scale.
Why slow, memory-hard hashing matters
Fast general-purpose hashes are excellent for file integrity and poor for password storage because attackers can test enormous numbers of guesses. Password-hashing functions deliberately consume time and, in modern designs, memory.
OWASP recommends Argon2id as the preferred choice, with scrypt as a fallback and appropriately configured bcrypt or PBKDF2 for particular legacy or compliance cases.[1] Exact parameters should be benchmarked and revisited as hardware changes. The goal is to make legitimate login acceptable and mass guessing expensive.
What is a pepper?
A pepper is a secret value kept separately from the password database, typically in a secrets-management system or hardware security module. If an attacker steals only the database, the missing pepper adds a barrier. Unlike a per-user salt, a pepper is secret and may be shared across many records.
Peppering adds operational complexity. If the pepper is exposed, changing it usually requires users to authenticate or reset passwords. It is defense in depth, not a substitute for proper hashing.
What defenders should do
For individuals
- Use a password manager to generate a unique password for every service.
- Protect the manager with a long, unique master passphrase and strong MFA.
- Prefer passkeys on important accounts.
- Never approve an unexpected login prompt.
- Change exposed passwords promptly, beginning with email and identity accounts.
- Review sessions and recovery methods after compromise.
For service operators
- Use a current password-hashing library and safe Argon2id, scrypt, bcrypt, or PBKDF2 configuration appropriate to the environment.
- Generate a unique salt automatically for every password.
- Block known compromised and common passwords.
- Permit long passwords, paste, and password managers.
- Rate-limit intelligently and detect spraying and stuffing across accounts and networks.
- Offer phishing-resistant authentication and secure recovery.
- Protect session cookies, reset tokens, and credential-change workflows.
- Monitor password-hash parameters and rehash after successful login when upgrades are needed.
Why arbitrary password changes can backfire
Forced frequent rotation often leads to predictable variations and written-down credentials. Change passwords when compromise is suspected or confirmed, when a shared secret must be separated, or when policy and risk require it. Otherwise prioritize length, uniqueness, breach screening, strong storage, and MFA.
A safe learning example
In an authorized lab, store a test password using a standard password-hashing library, inspect the encoded result, and verify that hashing the same password twice produces different stored strings because each uses a new salt. Then measure how increasing the cost affects verification time. This demonstrates the defensive concepts without targeting real credentials.
Do not test leaked credentials or third-party accounts. Password auditing belongs only in systems you own or have explicit permission to assess.
The bottom line
“Cracking” combines several different problems. Unique passwords stop reuse. Rate limits and detection constrain online guessing. Passkeys resist phishing. Secure endpoints reduce theft. Slow, salted password hashing makes a stolen database far more expensive to exploit. Strong systems layer all of them.
Sources
OWASP Cheat Sheet Series, Password Storage Cheat Sheet. ↩︎
