Practical documentation · Authorized use only

John the Ripper

John the Ripper supports offline password-strength auditing. Use synthetic or owner-supplied test hashes only, verify formats and benchmarks, report aggregate outcomes, and avoid rules, masks, wordlists, or distributed tuning that would enable unauthorized recovery.

CrackingPasswordsCPU

Start safely and get useful results

Best for

• Offline password-policy labs
• Hash-format and benchmark review

Not for

• Third-party hash cracking
• Real credential recovery

Before you run anything

• Document the authorized target, time window, success criteria, data-handling rules, and a named stop contact before you begin.
• Confirm the installed version with the tool’s version or help command, then compare its documented behavior with the linked upstream project before relying on any option.

Practical workflows

Beginner

Benchmark the local installation

Scenario: Establish password-audit workstation capability with no credential material.

john --test

Run the built-in benchmark and record CPU, version, and relevant format results.

Expected use: Benchmark data helps size a lab exercise; it is not a password-risk conclusion.

Intermediate

Verify supported hash formats

Scenario: A synthetic lab needs a known test format.

john --list=formats

List supported formats and document the exact synthetic format used in the exercise.

Expected use: Report aggregate recovery and policy improvement metrics only.

Interpret results like an analyst

• Format detection and benchmark rate are prerequisites; policy conclusions need controlled representative test material.
• Modern password posture also depends on MFA, rate limits, and breach-password controls.

Common mistakes and operating tips

Avoid

• Using a benchmark result as a real-world recovery estimate.
• Retaining plaintext or source hashes beyond the authorized audit window.

Operational discipline

• Treat command output as evidence, not a conclusion: retain the command, version, scope, timestamp, and a redacted result in the engagement record.
• Start with the smallest safe scope, validate expected behavior in a lab or pilot, then expand only when the authorization and monitoring plan support it.

Verify against the current upstream

Tool behavior and release syntax can change. Treat this guide as practical operating context, then verify version-specific details against the upstream project before an assessment.

Open authoritative upstream documentation