Password storage, and what cracking tools prove
John the Ripper and Hashcat test whether a stored secret is guessable. The lesson is the storage and the policy, not a recipe for guessing.
Diagram
From a stored verifier to a policy change
The system keeps a slow, salted verifier, not the password.
# Store # The system keeps a slow, salted verifier, not the # password.
The example on the open step is one illustration, or the fix you can paste into an application you own.
What is actually stored
A competent system does not store the password. It stores a slow, salted hash: a one-way result that is expensive to recompute and different for every user. When a database of those hashes leaks, an attacker can try guesses offline, away from your lockout policy. The cost of each guess is the whole defense. A fast hash, or an unsalted one, makes that offline work cheap.
Cracking tools exist to measure that cost. Given a hash and a way to recognize the algorithm, they try candidates and report the ones that match. In an authorized test or an internal audit, a quick match means the password was weak or the hash was too fast. That is the finding. The matched password itself is toxic. Do not paste it into a ticket, a slide, or a chat.
What the result should change
If guesses succeed, the control is not “ask users to try harder” alone. Use a slow password hash meant for passwords, screen new passwords against breach lists, require a phishing-resistant second factor on anything that matters, and stop reusing the same secret across systems. Length and a breach check beat ornate complexity rules that people dodge with predictable suffixes.
Online guessing, against a live login, is a different event. It shows up in the identity log as many failures. The control there is rate limiting, MFA, and alerting, which you can study in the sign-in mission of the browser lab. Offline guessing only happens after the hash has already left the building.
If you practice this
Generate a hash of a password you invented for the exercise, on a machine that is not your real login. Confirm the tool can recognize the algorithm. Then throw the password away. The skill is knowing what a fast match implies about storage and policy.
Do not point a wordlist at a hash you found on a network, in a repo, or in a dump you do not own. That is not a lab. Hashes in other people’s breaches are not course material.
Check yourself
Recognition and the fix. Nothing here is a procedure.
A general-purpose hash of a password matches a guess immediately. What failed?
Go deeper
Specific techniques, exercises, and glossary cards for this topic.
- 01How password hashes are cracked, and what makes stored passwords resist itOffline cracking turns a stolen hash database into passwords using dictionaries, rules, and masks. Includes the diagram and a defensive fix.
- 02Slow password hashesA password database will be copied eventually. Includes the diagram and a defensive fix.
- 03Password policy that follows NIST SP 800-63B: length, screening, and no forced rotationModern guidance favors long passphrases, screening against breached passwords, no arbitrary complexity rules or scheduled rotation, and password managers plus MFA. Includes the diagram and a defensive fix.
Exercises
- 01Password policy and hash cost explorerChange length, character sets, and hash algorithm, and watch the offline guessing time move. Then test which policy-compliant passwords fall first anyway.
- 02Password hashing and salting visualizerSee what a leaked user table reveals with no salt, one site-wide salt, and per-account salts, using real SHA-256 hashes computed in your browser.