CYBERSECURITY • PASSWORD AUDITING
John the Ripper: Complete Guide to Password Auditing
John the Ripper is one of the most widely used password-auditing and password-recovery tools in cybersecurity. It can test password hashes using dictionary attacks, word-mangling rules, single-crack techniques, incremental attacks, and other configurable methods.
⚠️ Authorization & Legal Notice
John the Ripper should only be used for systems, password hashes, files, and accounts that you own or have explicit authorization to audit.
The examples in this guide are intended for cybersecurity education, laboratory environments, password auditing, and authorized penetration testing. Do not use recovered credentials or password hashes to access accounts or systems without permission.
1. What Is John the Ripper?
John the Ripper (JtR) is a password-cracking and password-auditing tool originally designed to identify weak Unix passwords. Modern versions support a very large collection of password-hash and encrypted-file formats, particularly in the Jumbo build.
The fundamental idea is simple: John takes a password hash and generates candidate passwords. It applies the appropriate hashing process to each candidate and compares the resulting value with the target hash. When the values match, the original password has been recovered.
John combines several cracking modes and is highly configurable. Its official documentation describes wordlist, single-crack, incremental, and external modes among its major capabilities.
2. Why Is John the Ripper Important?
Password auditing is important because a password can appear strong to a human while still being predictable to an automated password-auditing tool.
Security professionals can use John to:
- Identify weak passwords in an authorized password audit.
- Evaluate organizational password policies.
- Test the effectiveness of password hashing.
- Recover passwords from authorized encrypted data.
- Demonstrate the risks of password reuse.
- Evaluate custom password dictionaries and rules.
- Support incident-response and forensic investigations.
3. How Password Cracking Works
John does not normally "decrypt" a password hash. A cryptographic password hash is designed to be one-way. Instead, John generates possible passwords and tests them against the hash.
For example, if a laboratory hash corresponds to the password Cyber123!, John may eventually generate that candidate. If its calculated hash matches the target hash, the password has been recovered.
4. Password Hashes: The Theory You Need
Hashing vs Encryption
Encryption is designed to be reversible when the correct key is available. Hashing is designed as a one-way transformation.
Password systems therefore normally store a password-derived hash rather than the plaintext password.
Salts
A salt is additional random data incorporated into password hashing. Properly designed salted password hashing makes precomputed attacks much less useful and ensures that identical passwords do not necessarily produce identical stored hashes.
Fast vs Slow Password Hashing
Algorithms designed for password storage intentionally make password verification computationally expensive. Modern password hashing approaches such as bcrypt, scrypt, and Argon2 are designed to make large-scale guessing substantially more expensive than using fast general-purpose hashes.
This is why the hash algorithm matters just as much as the password itself when evaluating password security.
5. Installing John the Ripper
Kali Linux / Debian-based Linux
sudo apt update
sudo apt install johnVerify the installation:
john --versionDepending on the operating system and package, the available formats and features can differ. For advanced auditing, security professionals should understand whether they are using a standard John build or a Jumbo build.
6. Basic John the Ripper Syntax
john [options] [password-file]The password file contains password hashes or another supported input format. Options control the attack mode, hash format, wordlist, session handling, and other behavior.
Basic execution
john hashes.txtWith no specific cracking mode selected, John follows its configured sequence of cracking modes. The official examples describe a typical progression beginning with single-crack mode, followed by wordlist mode and then incremental mode.
7. John the Ripper Cracking Modes
Choosing the correct mode is one of the most important parts of using John efficiently.
7.1 Single Crack Mode
Single-crack mode generates candidates using information associated with accounts, such as login names and GECOS/full-name information, together with password-mangling rules.
john --single hashes.txtThis mode can be very effective when passwords are based on predictable personal information.
7.2 Wordlist Mode
Wordlist mode tests candidate passwords from a text file. Each line normally represents a candidate word.
john --wordlist=/path/to/wordlist.txt hashes.txtWordlists are particularly effective when passwords are based on common words, leaked-password patterns, names, locations, brands, or predictable modifications.
7.3 Wordlist + Rules
John can transform words from a wordlist using rules. This allows one source word to generate many password candidates.
john --wordlist=/path/to/wordlist.txt --rules hashes.txtFor example, a source word such as security could be transformed into multiple variations involving capitalization, numbers, substitutions, or appended characters.
7.4 Incremental Mode
Incremental mode can attempt combinations across a configured character set. It is extremely powerful but can have an enormous search space.
john --incremental hashes.txtIncremental mode does not simply generate random strings. John uses character-frequency information to prioritize candidates. Because the theoretical search space can become enormous, such attacks may run for a very long time.
7.5 External Mode
Advanced users can define custom candidate-generation or filtering logic using John's external mode and configuration system.
john --external=MODE hashes.txtExternal modes are useful when standard candidate-generation strategies do not adequately represent a specific authorized auditing scenario.
8. Wordlists
A wordlist is simply a collection of candidate passwords. The quality and ordering of a wordlist can have a major effect on auditing efficiency.
A useful wordlist may contain:
- Common passwords.
- Dictionary words.
- Common password variations.
- Organization-approved test passwords.
- Custom laboratory candidates.
Example custom wordlist
nano lab-wordlist.txtExample contents:
password
Password
Password123
Security123
Cybersecurity
Cyber123!Use only intentionally created test data in a learning environment.
9. RockYou and Large Wordlists
Kali Linux commonly includes the RockYou wordlist in compressed form. Depending on the installation, its location may be:
/usr/share/wordlists/rockyou.txt.gzIf the file is present and you are working in an authorized laboratory, it can be decompressed before use.
sudo gzip -d /usr/share/wordlists/rockyou.txt.gzLarge wordlists can significantly increase the number of candidates tested, but larger does not automatically mean better. A smaller, well-targeted wordlist can sometimes be considerably more efficient.
10. John the Ripper Rules
Rules are one of John's most powerful features. Instead of testing only the exact words in a wordlist, rules modify those words to generate additional candidates.
Conceptually:
word
↓
capitalize
↓
append number
↓
append symbol
↓
password candidateJohn provides an extensive rule syntax supporting transformations, reject conditions, character classes, variables, and preprocessing.
This makes rules useful for modelling common human password construction behavior.
Using the default rules
john --wordlist=wordlist.txt --rules hashes.txtCustom rules can be defined in John's configuration file.
11. Hash Formats
John supports many different password and encrypted-data formats. The exact formats available depend on the build.
You can inspect available formats with:
john --list=formatsWhen automatic detection does not select the expected format, a format can be explicitly specified:
john --format=FORMAT hashes.txtUsing the wrong format is a common reason for messages such as No password hashes loaded.
12. Monitoring a Cracking Session
John can report the current state of a running or interrupted session.
john --statusDuring a running session, pressing a key in the terminal can also cause John to display its current status.
Depending on the mode, useful information can include candidate rate, progress, elapsed time, and the current cracking state.
13. Sessions and Long-Running Jobs
Password auditing can take minutes, hours, or substantially longer. John therefore provides session management.
Create a named session
john --session=lab-audit hashes.txtCheck status
john --status=lab-auditRestore a session
john --restore=lab-auditNamed sessions are especially useful when several authorized password-auditing jobs are being performed.
14. Displaying Recovered Passwords
John stores recovered password information in its internal password database, commonly referred to as the john.pot file.
Use John's own interface to display recovered passwords:
john --show hashes.txtThis is preferable to manually inspecting the internal pot file.
15. Complete Authorized Laboratory Workflow
The following workflow demonstrates the general process without targeting real credentials.
Step 1 — Prepare a laboratory hash
Create a password and corresponding hash using a controlled laboratory environment.
Step 2 — Save the hash
nano hashes.txtStep 3 — Prepare a small wordlist
nano lab-wordlist.txtStep 4 — Run a dictionary audit
john --wordlist=lab-wordlist.txt hashes.txtStep 5 — Display results
john --show hashes.txtStep 6 — Try word-mangling rules
john --wordlist=lab-wordlist.txt --rules hashes.txtStep 7 — Monitor a named session
john --session=lab hashes.txtjohn --status=labStep 8 — Restore if interrupted
john --restore=labThis workflow illustrates the fundamental password-auditing lifecycle:
16. Understanding Incremental Attacks
Incremental mode attempts combinations from a configured character set. The theoretical search space grows rapidly as password length increases.
If a character set contains N possible characters and the password length is L, the number of possible combinations for exactly that length is:
N^LFor example, a 10-character password selected from 62 possible alphanumeric characters has:
62^10possible combinations before considering smarter candidate ordering or password-specific weaknesses.
This demonstrates why password length, character space, hashing cost, and candidate-generation strategy all matter.
17. Performance and Cracking Speed
John reports password-candidate processing rates, but raw speed should never be interpreted as the complete measure of password security.
Performance depends on factors such as:
- Hash algorithm.
- Password length.
- Number of candidate passwords.
- Number of hashes.
- Salt configuration.
- CPU performance.
- Parallelization.
- John build and implementation.
- Selected cracking mode.
Fast hashes can be tested extremely quickly, while deliberately expensive password-hashing algorithms significantly reduce the number of guesses an attacker can perform.
18. Benchmarking John
John includes benchmarking functionality for evaluating the performance of supported algorithms.
john --testYou can also restrict testing to a particular supported format:
john --test --format=FORMATBenchmark results are useful when evaluating the relative performance of different systems or configurations.
19. John's Configuration System
John is highly configurable. Its configuration file can define global options, wordlists, rules, incremental modes, and external modes.
Depending on the platform, the configuration file is generally called:
john.confor:
john.iniAdvanced users can customize John to represent specific authorized password-auditing requirements.
20. Common Problems and Solutions
"No password hashes loaded"
Possible causes:
- Incorrect hash format.
- Malformed input.
- Unsupported format.
- Incorrect file contents.
Approach:
john --list=formatsVerify that the supplied hash corresponds to a format supported by the installed build.
Wordlist not found
Verify the path:
ls -lh /path/to/wordlist.txtJohn is taking too long
This may be completely normal. Incremental attacks can have enormous search spaces, and slow password hashes intentionally reduce candidate-processing speed.
Consider the selected mode, wordlist size, rules, hash algorithm, password length, and available hardware before assuming something is broken.
Session interrupted
Use a named session and restore it:
john --restore=lab21. John the Ripper vs Hashcat
John the Ripper and Hashcat are both powerful password-auditing tools, but their workflows and strengths differ.
| Feature | John the Ripper | Hashcat |
|---|---|---|
| Primary use | Password auditing and recovery | Password recovery and auditing |
| CPU usage | Strong | Supported |
| GPU focus | Available depending on build/workflow | Major strength |
| Rules | Very powerful | Very powerful |
| Formats | Extensive, especially Jumbo | Extensive |
| Learning curve | Moderate | Moderate to advanced |
The right tool depends on the hash type, hardware, workflow, required attack strategy, and auditing objective.
22. John the Ripper vs Hydra
John and Hydra solve different problems.
- John the Ripper: Primarily focused on offline password/hash auditing and password recovery.
- Hydra: Primarily designed for testing authentication services and network login mechanisms in authorized environments.
They should not be treated as interchangeable tools.
23. What John Teaches Us About Password Security
The most valuable result of a password audit is not the recovered password itself. It is understanding why that password was recoverable.
Use strong passwords
Longer, unpredictable passwords dramatically increase the candidate search space.
Avoid password reuse
Reusing passwords creates a single point of failure. A compromised password can potentially affect multiple services.
Use password managers
Password managers make it practical to use unique, high-entropy passwords for different services.
Use MFA
Multi-factor authentication provides an additional security layer even if a password is compromised.
Use modern password hashing
Applications should use password-specific, deliberately expensive hashing algorithms with unique salts rather than fast general purpose hashes.
24. John the Ripper Command Cheat Sheet
| Command | Purpose |
|---|---|
john hashes.txt | Run John's default cracking sequence. |
john --single hashes.txt | Use single-crack mode. |
john --wordlist=words.txt hashes.txt | Use a specified wordlist. |
john --wordlist=words.txt --rules hashes.txt | Use wordlist mode with rules. |
john --incremental hashes.txt | Use incremental mode. |
john --format=FORMAT hashes.txt | Force a specific hash format. |
john --show hashes.txt | Display recovered passwords. |
john --status | Display session status. |
john --session=NAME hashes.txt | Start a named session. |
john --restore=NAME | Restore an interrupted session. |
john --test | Benchmark supported algorithms. |
john --list=formats | List available hash formats. |
25. Recommended Password-Auditing Workflow
- Obtain explicit authorization.
- Identify the hash format.
- Preserve the original evidence.
- Start with efficient candidate sources.
- Use an appropriate wordlist.
- Apply rules when justified.
- Use single-crack techniques when appropriate.
- Use incremental techniques only when the search space is reasonable.
- Monitor performance and session state.
- Document recovered and unrecovered credentials securely.
- Report password-policy weaknesses.
- Recommend remediation.
26. Final Takeaway
John the Ripper is more than a simple password-cracking command. It is a flexible password-auditing framework that combines candidate generation, wordlists, rules, hash formats, session management, incremental attacks, benchmarking, and extensive configuration.
The most important concept is understanding the relationship between password entropy, candidate generation, hash algorithms, computational cost, and time.
Used responsibly, John can help security professionals discover weak passwords before attackers do and provide measurable evidence for improving an organization's authentication security.
