John the Ripper Password Cracking: 7 Smart Lab Steps

John the Ripper password cracking is a practical way to test how quickly weak passwords can fall when an attacker already has access to their hashes. Instead of attacking a live login page, John works offline: you give it a password hash, it generates or reads possible passwords, hashes those candidates, and looks for a match. In your own ethical hacking lab, that makes John the Ripper an excellent tool for understanding the difference between a password that merely looks complicated and one that is actually difficult to guess.

This John the Ripper tutorial is built around 7 safe lab tests using hashes and passwords that you create yourself. I am not interested in dumping real credentials from somebody else’s computer. I want to see what happens when I deliberately create weak passwords, change the wordlist, apply rules, switch cracking strategies, and study the results. Those are the same 7 smart lab steps I would rather understand than replace with fifty unexplained commands.

If practical cybersecurity experiments are more useful to you than recycled lists of terminal commands, you can also join my HackersGhost newsletter. I use it for new lab guides, security observations, and the occasional reminder that the terminal is usually doing exactly what I told it to do, even when that turns out not to be what I meant.

Everything in this John the Ripper password cracking guide assumes that you are working with passwords, hashes, files, and systems you own or have explicit permission to test. For beginners, self-created hashes are actually better training material because you already know the answer and can concentrate on understanding why John succeeds or fails.

Lab test	What you change	What it teaches you
Wordlist cracking	Candidate passwords	Why predictable passwords fail
Rules and formats	Candidate mutations and hash handling	Why context matters
Incremental testing	Search strategy	Why password length changes the game

Key Takeaways

• John the Ripper is not a login brute-forcing tool. Its core strength is offline password security auditing and recovery using hashes you already possess legitimately.
• John the Ripper password cracking is heavily influenced by candidate quality. A smart five-line wordlist can crack a deliberately weak lab password faster than a huge irrelevant list.
• A hash is not an encrypted password waiting for John to decrypt it. John tests candidate passwords and looks for matching hash output.
• John the Ripper rules can transform ordinary words into additional candidates, which is one reason predictable substitutions are weaker than many users expect.
• When John the Ripper password cracking fails, that does not automatically prove a password is strong. Your attack strategy may simply not have generated the right candidate.
• The most useful result is not the dramatic sight of a password appearing in your terminal. It is understanding why that password became guessable.
• By the end of these tests, you will have a small practical John the Ripper cheat sheet you actually understand instead of one you saved somewhere and forgot about.

What Is John the Ripper?

John the Ripper is an open-source password security auditing and password recovery tool. It supports many password hash and cipher formats, with the Jumbo edition considerably extending what the tool can handle. That includes hashes associated with operating systems, archives, encrypted files, applications, and other formats.

The important concept behind John the Ripper password cracking is simple. Suppose the password is ghostlab and you create a hash from it. John does not reverse that hash through some secret mathematical trapdoor. It tries a candidate such as ghostlab, processes that candidate using the appropriate algorithm, and checks whether the result matches the stored hash.

That difference matters. It explains why the quality of your candidate generation is so important. If your wordlist never contains the right password, and your rules never generate it, the correct candidate may never be tested.

The official Openwall project describes several cracking modes. Wordlist mode reads possible passwords from a file. Single crack mode can derive candidates from account-related information in suitable password files. Incremental mode generates candidates based on character sets and statistical information. For this beginner lab, I concentrate mostly on controlled wordlists and one deliberately tiny incremental exercise.

HackersGhost Note: I think beginners learn more when they stop thinking of John as a mysterious “password cracker” and start seeing it as a candidate-testing engine. Once that clicked for me, wordlists, rules, formats, and failed cracks all started making much more sense.

My John the Ripper Ethical Hacking Lab

I run most of my ethical hacking experiments from a second-hand HP EliteBook. I added another 16 GB of RAM to bring it to 32 GB, which gives me plenty of room for VMware and multiple lab machines. I keep Kali Linux available, but Parrot OS is still the distro I use most often.

My vulnerable machines stay separated from normal everyday systems. I also use a Cudy WR3000 for external traffic with ProtonVPN WireGuard and Secure Core, while a TP-Link Archer C6 is reserved for controlled network experiments. None of that is required for John the Ripper password cracking, because these exercises can remain entirely inside one Linux VM. That is one of John’s advantages for learning: you do not even need a vulnerable network target to start.

For the seven tests below, I create the hashes myself. There is no credential extraction, no wandering into somebody else’s machine and no need to connect a deliberately vulnerable router just because it happens to look lonely.

HackersGhost Note: My rule is simple: if I can reproduce the lesson with a password I invented thirty seconds ago, I do not need a stranger’s credentials to make the demonstration more “real.” The learning happens in the methodology, not in who owns the hash.

How to Install John the Ripper for Linux

If you are searching for how to install John the Ripper, first check whether it is already available:

john --help

On Kali Linux, the package can be installed with APT:

sudo apt update
sudo apt install john

The official Kali Linux project maintains documentation for John in its tool collection. On another Debian-based security distribution, including the kind of Parrot OS environment I use, I still check the available package and version instead of assuming every distro ships precisely the same build.

After your John the Ripper installation, these commands are useful sanity checks:

john --help
john --list=formats | head

The second command is associated with Jumbo-capable builds. If an option in this John the Ripper tutorial behaves differently on your package, start with john --help and the documentation shipped with your version rather than arguing with the terminal. The terminal has dreadful bedside manners but an excellent memory for syntax.

Password Cracking: 7 Reasons Weak Passwords Fail Fast

Password Cracking: 7 Reasons Weak Passwords Fail Fast

John the Ripper Password Cracking Test 1: Make Your Own Hash

My first John the Ripper password testing exercise removes every unnecessary variable. I choose a deliberately weak password, create its hash myself, then crack only that hash.

Create a raw MD5 hash for the lab password ghostlab:

printf 'ghostlab' | md5sum | cut -d ' ' -f1 > lab-hash.txt
cat lab-hash.txt

Raw MD5 is useful here because it keeps the mechanics visible and the exercise fast. I am not recommending raw MD5 for storing real passwords. The point is to create a disposable teaching hash whose original value I already know.

Now create a tiny wordlist for John the Ripper:

printf "admin\npassword\nghost\nghostlab\nletmein\n" > lab-words.txt

Run John the Ripper password cracking against the hash:

john --format=raw-md5 --wordlist=lab-words.txt lab-hash.txt

Because ghostlab appears directly in the list, John should find it quickly. That is not impressive computational power; it is a controlled demonstration of candidate matching. The password failed because I placed the correct candidate in front of the tool.

Display the recovered result with:

john --show --format=raw-md5 lab-hash.txt

This first password cracking with John the Ripper exercise establishes the entire workflow: create a known hash, supply candidates, select the format, run the test, then inspect the result.

John the Ripper Password Cracking Test 2: Remove the Correct Password

Now I change only one thing. I create another wordlist without ghostlab:

printf "admin\npassword\nghost\nletmein\nwelcome\n" > wrong-words.txt

john --format=raw-md5 --wordlist=wrong-words.txt lab-hash.txt

This John the Ripper password cracking run should not recover the password through that list because the correct candidate is absent. The hash has not become stronger. John has not suddenly become weaker. You simply changed the candidate pool.

This is one of the most useful concepts in John the Ripper the basics. A failed wordlist attack means the password was not recovered with those candidates. It does not prove that the password would resist every other sensible strategy.

It also explains why blindly downloading the largest possible password list is not automatically clever. In a real authorized password audit, knowledge about password policy, language, organizational naming patterns, and likely human behavior can influence the quality and ordering of candidates. In my beginner lab, I deliberately keep that context artificial and harmless.

HackersGhost Note: This test looks almost too simple, but it cured me of a bad beginner assumption: “John didn’t crack it, so it must be strong.” No. Sometimes John simply never knocked on the right door.

John the Ripper Password Cracking Test 3: Compare Weak Password Patterns

For the third test, I want to show why predictable patterns matter. Create three known lab hashes:

printf 'dragon' | md5sum | cut -d ' ' -f1 > hash-one.txt
printf 'dragon7' | md5sum | cut -d ' ' -f1 > hash-two.txt
printf 'purple-river-copper-lamp' | md5sum | cut -d ' ' -f1 > hash-three.txt

Then create a small targeted wordlist:

printf "password\ndragon\ndragon1\ndragon7\nwelcome\n" > patterns.txt

Test the first two hashes:

john --format=raw-md5 --wordlist=patterns.txt hash-one.txt
john --format=raw-md5 --wordlist=patterns.txt hash-two.txt

Both lab passwords are directly represented in the candidate list. The longer passphrase in hash-three.txt is not. If you run the same wordlist against it, that test should finish without finding the original passphrase.

This is where John the Ripper password security becomes more interesting than counting characters. Adding one predictable digit to a common word can make the password longer without making it particularly surprising. A substantially longer, unique passphrase that is not based on a predictable pattern gives this tiny wordlist nothing useful to work with.

Again, failure here is not a mathematical certificate of strength. It tells me that the stronger candidate resisted this specific John the Ripper password cracking strategy. That distinction is worth keeping.

John the Ripper Password Cracking Test 4: Learn John the Ripper Rules

John the Ripper rules are where wordlist testing becomes more flexible. Instead of trying only the literal contents of a file, rules can transform source words into additional candidates.

Create a tiny base list:

printf "ghost\ndragon\nadmin\n" > base-words.txt

Before aiming rules at any hash, I prefer to see what candidate generation is doing:

john --wordlist=base-words.txt --rules --stdout | head -n 30

Depending on the build and configured rules, you will see transformations derived from the original words. This is a useful way to learn John the Ripper commands without turning every experiment into a cracking run.

The security lesson is straightforward. Humans often make password changes that look inventive to humans but remain structurally predictable: capitalization, appended digits, common punctuation, or familiar substitutions. Rule-based John the Ripper password cracking exists precisely because candidate generation can model some of those habits.

You can apply the configured wordlist rules with syntax such as:

john --format=raw-md5 --wordlist=base-words.txt --rules your-lab-hash.txt

I recommend using --stdout first when learning. Seeing the mutations removes some of the mystery from John the Ripper syntax and helps you understand why a rule-assisted test may discover something the original wordlist could not.

HackersGhost Note: Rules are where “but I changed the first letter and added something at the end” stops sounding like a security strategy. Human creativity is often much more predictable than human confidence.

John the Ripper Password Cracking Test 5: Understand Hash Formats

One of the most common beginner problems is not password strength at all. It is format handling. John needs to understand what kind of hash or encrypted data you gave it.

In our previous tests I explicitly used:

--format=raw-md5

That tells John exactly how to interpret the test hash. To see formats exposed by a compatible Jumbo build, try:

john --list=formats

If you encounter the familiar John the Ripper “No password hashes loaded” message in your own legitimate lab, do not immediately start changing cracking modes. Check the input first. Is it actually a supported hash? Does it need conversion? Is the format being detected correctly? Is the file structured as John expects?

This is why the many helper utilities associated with Jumbo exist. Different encrypted archives, documents, keys, and other containers may need information extracted into a form John can test. For a beginner John the Ripper lab tutorial, however, raw hashes you create yourself are much cleaner because you are learning format selection without adding file extraction to the puzzle.

The larger lesson from this John the Ripper password cracking test is that syntax and data preparation matter. A perfectly good wordlist cannot rescue malformed or misunderstood input.

John the Ripper Password Cracking Test 6: Try a Tiny Incremental Search

Wordlists test candidates you supply or derive. Incremental mode explores candidates differently. Openwall describes incremental mode as a powerful cracking mode that can generate character combinations, and the search space can become enormous. That last part is the lesson I care about.

For a safe demonstration, create a deliberately tiny numeric password:

printf '042' | md5sum | cut -d ' ' -f1 > digits-hash.txt

Then run the Digits incremental mode:

john --format=raw-md5 --incremental=Digits digits-hash.txt

Because the password is intentionally tiny, John the Ripper password cracking should reach it quickly on a normal modern system. Do not use this result to conclude that incremental mode can casually defeat any long password. The number of possible combinations grows rapidly as you add length and character possibilities.

That growth is exactly why this three-digit test is useful. You get to see how to use John the Ripper in incremental mode without leaving your machine performing an effectively pointless search through a massive candidate space.

For me, this is a much better demonstration of password length than vague advice that “longer is better.” The reason becomes visible: every additional position can multiply the amount of work required when the attacker cannot narrow the candidate set intelligently.

John the Ripper Password Cracking Test 7: Read the Result Like a Defender

The final test contains almost no new syntax. Instead, I compare what the earlier John the Ripper password cracking results actually tell me.

• ghostlab fell immediately because it appeared literally in the wordlist.
• dragon7 was still predictable because the full candidate was present in a small pattern-based list.
• The longer unique passphrase survived that list because we never generated the matching candidate.
• Rules expanded what a base wordlist could try, demonstrating why obvious human mutations should not be treated as strong uniqueness.
• The three-digit password was appropriate prey for incremental testing because its search space was deliberately tiny.

This is the point where John the Ripper ethical hacking becomes defensive knowledge. I am not just collecting cracked values. I am asking what property caused each password to fail and how I would prevent the same weakness in an account that matters.

A good conclusion from John the Ripper password cracking is not “every password can be cracked instantly.” That would be nonsense. A better conclusion is that predictability dramatically reduces the attacker’s guessing problem. Long, unique passwords or passphrases generated without obvious patterns make that problem far less convenient.

HackersGhost Note: Watching John recover a password is satisfying for about five seconds. Understanding why it recovered that password is the part worth carrying into your real security habits.

FFUF Tutorial for Beginners: 9 Practical Fuzzing Examples

FFUF Tutorial for Beginners: 9 Practical Fuzzing Examples

My Practical John the Ripper Cheat Sheet

I do not memorize every possible switch. These are the John the Ripper commands I would keep beside a beginner lab:

• john --help — check the command-line options supported by your build.
• john --wordlist=FILE HASHFILE — run a wordlist-based test.
• john --format=NAME ... — force the expected hash format when appropriate.
• john --show HASHFILE — display passwords John has already recovered for that input.
• john --wordlist=FILE --rules HASHFILE — apply configured wordlist rules.
• john --wordlist=FILE --rules --stdout — inspect generated candidates instead of cracking.
• john --incremental=Digits HASHFILE — run the Digits incremental mode.
• john --list=formats — list supported formats on compatible Jumbo builds.

That is enough John the Ripper syntax for the seven exercises in this article. Add options when they solve a problem you actually understand. Collecting switches for their own sake is how a useful tool becomes terminal wallpaper.

John the Ripper vs Hashcat: Which Should You Learn?

John the Ripper vs Hashcat is not a question where I think a beginner needs to crown one permanent winner. Both are established password auditing tools, but their workflows and strengths are different enough that learning one does not make the other pointless.

I like John the Ripper for Linux because the basic workflow is extremely approachable: give John a supported hash, select a wordlist or cracking mode, and study what happens. John Jumbo also brings a large ecosystem of supported formats and conversion helpers.

Hashcat is also highly capable and is particularly well known for accelerated password recovery workflows. If your goal is eventually to explore GPU-heavy auditing and performance tuning, it deserves its own lab time. But I would not turn hashcat vs John the Ripper into a distraction while learning the fundamentals.

Understand candidate generation, hash formats, wordlists, rules, and search-space growth first. Those concepts transfer. The logo on the terminal matters less than understanding what the terminal is doing.

What John the Ripper Password Cracking Changed in My Own Password Habits

Testing weak passwords myself changed how I think about password advice. “Use a complex password” is vague. Watching a predictable candidate appear in a tiny list is not vague at all.

I now care much more about uniqueness and unpredictability than about cosmetic complexity. A familiar word with a capital letter and a digit may satisfy some policy rules while still resembling the patterns a password audit is designed to test.

I also do not expect myself to memorize a different strong password for every account. That is where a password manager fits naturally into the lesson from John the Ripper password cracking: generate unique credentials, store them securely, and remove the temptation to recycle memorable patterns across services.

Why I Pair Password Testing With a Password Manager

After deliberately creating weak passwords for this lab, I do not want the lesson to end with “try harder when inventing passwords.” Humans are very good at creating patterns and then being surprised that other humans also thought of them.

For everyday accounts, I prefer using a password manager to generate and store unique credentials. NordPass is one option that fits this workflow well. Its password manager handles password generation and encrypted storage, while Premium features include Password Health for identifying weak, old, exposed, or reused credentials and a Data Breach Scanner for additional visibility.

That complements John the Ripper password security nicely. John shows me in the lab why weak and predictable choices are a problem; a password manager helps me avoid creating those patterns repeatedly in daily life.

I use password-cracking labs to understand weak credential patterns; a password manager is the more practical place to apply that lesson to everyday accounts.

I would still keep the two concepts separate. A password manager is not a magical shield against phishing, malware, poor account recovery settings, or every possible breach. What it does very well is remove one large source of avoidable weakness: asking you to invent and remember dozens of unique strong passwords yourself.

A Useful Parrot OS Book for Building the Bigger Lab

Because I perform most of my own John the Ripper password cracking tests from Parrot OS, a broader Parrot reference can be useful once you want to connect password auditing with Linux security, penetration testing, digital forensics, and the rest of your lab workflow.

Mastering Parrot OS for Ethical Hacking is aimed at that wider learning path rather than John alone. I see a book like this as supporting material: useful beside the keyboard, but not a replacement for creating the hash, running the command, breaking the command, fixing it, and understanding why it finally worked.

Beginner Mistakes I Would Avoid With John the Ripper

Assuming Every Failed Crack Means a Strong Password

A failed John the Ripper password cracking run tells you that the password was not recovered by that test. Maybe the candidate never appeared. Maybe the format was wrong. Maybe your rules were inappropriate. Interpret the result in context.

Starting With Giant Wordlists

I learn more from five candidates I understand than millions I have never looked at. Start small. Confirm the hash, candidate, format, and expected result. Scale later.

Ignoring John the Ripper Password Cracking Formats

If John cannot interpret your input correctly, a bigger wordlist will not save you. Learn what --format means and why helper tools sometimes exist before treating every error as a cracking problem.

Treating Raw MD5 as a Real Password Recommendation

I use raw MD5 here only because it makes a fast, reproducible lab hash. The exercise is about learning John, not designing a real authentication database.

Testing Credentials You Do Not Own

You do not need somebody else’s password hashes to learn how to use John the Ripper in Kali Linux, Parrot OS, or another lab distro. Creating your own known inputs gives you cleaner experiments and a safer methodology.

How I Would Learn John the Ripper From Zero

If you are completely new to John the Ripper password cracking, I would repeat the seven tests in this order:

1. Create one known hash yourself. Remove uncertainty about where the input came from.
2. Crack it with a five-line wordlist. Learn what a successful match looks like.
3. Remove the correct candidate. See why a failed test needs context.
4. Inspect rule-generated candidates. Understand predictable password mutations.
5. Experiment with explicit formats. Learn why input preparation matters.
6. Run the tiny Digits incremental test. Observe a different candidate-generation strategy.
7. Explain the results in your own words. If you can explain why each password did or did not fall, the exercise has done its job.

After that, larger wordlists, more formats, custom rules, sessions, performance options, and John the Ripper vs Hashcat testing become meaningful extensions instead of disconnected commands.

Hydra Kali Linux: 7 Practical Tests on Parrot OS Too

Hydra Kali Linux: 7 Practical Tests on Parrot OS Too

Is John the Ripper Worth Learning for Beginners?

Yes. John the Ripper password cracking gives beginners a relatively transparent way to explore password security without needing a large network lab. One Linux VM, a few self-created hashes, and a tiny wordlist are enough to understand the fundamentals.

More importantly, John teaches concepts that outlive the individual commands: candidate generation, password predictability, hash formats, wordlists, rules, search spaces, and the difference between “not cracked” and “uncrackable.”

That is why I consider this a better beginner exercise than simply downloading a massive leaked password list and watching numbers move. John the Ripper password cracking becomes useful when the output makes you think differently about password design and auditing.

HackersGhost Note: My favorite lab tests are usually the small ones. When you already know the password and still deliberately make John fail, you start learning much more about the tool than when everything succeeds on the first command.

Final Thoughts on John the Ripper Password Cracking

This John the Ripper tutorial deliberately stayed small. We created our own hashes, tested custom wordlists, removed candidates, explored predictable patterns, inspected rules, selected formats, tried incremental mode, and interpreted the results from a defensive perspective.

That is enough to understand John the Ripper the basics without pretending that one article turns you into a password-cracking specialist. More advanced workflows can involve additional formats, conversion utilities, custom rules, performance tuning, sessions, and hardware considerations. They become much easier to learn once the foundation is clear.

The main lesson from John the Ripper password cracking is not that passwords are doomed. It is that predictable passwords make an attacker’s candidate-generation problem unnecessarily easy. Your lab lets you see that difference rather than simply accepting another security rule because somebody printed it in a checklist.

Create the hash. Make John succeed. Make it fail. Change one variable. Run it again. That is how I prefer learning security tools: controlled enough that I know what happened, practical enough that the lesson sticks, and with just enough terminal confusion to prevent excessive self-confidence.

Frequently Asked Questions