🔐 Password Cracking

Password Hashing

What is hashing

A password hash is the output of a one-way cryptographic function applied to a password. The same password always produces the same digest, but deriving the password from the digest should be computationally infeasible.

password  ──▶  [ hash function ]  ──▶  fixed-size digest
"P@ssw0rd" ──▶  [ SHA-256 ]      ──▶  6b3a55e0261b03…

Systems store the digest — not the password. Authentication hashes the submitted password and compares digests.

Why passwords are hashed

• Confidentiality — a database breach exposes digests, not plaintext credentials.
• Non-reversibility — a proper hash function cannot be inverted analytically.
• Verifiability — the server can still authenticate a user by re-hashing input.
• Separation of duties — administrators operate the platform without seeing user secrets.

Hash vs encryption

Hashing answers "is this the same value?". Encryption answers "what was the original value?". Storing passwords with encryption is an anti-pattern — the key becomes the crown jewel.

Common algorithms

• Fast general-purpose hashes — MD5, SHA-1, SHA-256, SHA-512. Built for speed and integrity, not password storage. Trivially parallelised on GPUs.
• Password-storage KDFs — bcrypt, scrypt, PBKDF2, Argon2, yescrypt. Deliberately slow and, in modern variants, memory-hard.
• Windows-specific — LM (broken, disabled since Vista), NTLM (unsalted MD4 of the UTF-16LE password), NetNTLMv1/v2 (network challenge-response).

Salting

A salt is a per-user random value mixed into the hash input.

digest = H(salt || password)

Salting defeats rainbow tables (precomputed hash → password lookups become useless per user) and duplicate detection (two users with the same password produce different digests).

A salt does not need to be secret. It only needs to be unique per credential and long enough — 16 bytes / 128 bits is standard.

Peppering

A pepper is a secret value, shared across the application, added to the hashing input and stored outside the credential database (for example in a KMS or app config):

digest = H(salt || password || pepper)

Compromise of the database alone no longer yields testable hashes — an attacker also needs the pepper. Peppers do not replace salts; they layer on top.

Password storage

• Store the algorithm identifier, cost parameters, salt and digest — usually in one Modular Crypt Format string such as $argon2id$v=19$m=65536,t=3,p=4$salt$digest.
• Never store plaintext, reversible encryption, or unsalted fast hashes.
• Re-hash transparently on next login when you raise cost parameters or migrate algorithms.
• Compare digests with constant-time functions to avoid timing leaks.

Hash Identification

Hash Identifier

The interactive identifier at the bottom of this page inspects prefix, length, character set and salt structure entirely in your browser, then lists likely algorithms with example offline analysis syntax.

HashID

• Purpose — identify the type of a hash from its structure.
• Platforms — Python, cross-platform.
• Typical use — quickly narrowing candidate algorithms during triage.
• Reference — https://github.com/psypanda/hashID

hashid '5f4dcc3b5aa765d61d8327deb882cf99'
hashid -m hashes.txt

Name-That-Hash

• Purpose — modern hash identifier with confidence scoring and metadata.
• Platforms — Python, cross-platform.
• Typical use — annotated identification with Hashcat / John mode suggestions and JSON output.
• Reference — https://github.com/HashPals/Name-That-Hash

nth --text '5f4dcc3b5aa765d61d8327deb882cf99'
nth -f hashes.txt -g

Detecting unknown hashes

Work through the structure in order:

• 32 hex chars → MD5 or NTLM (context decides).
• 40 hex chars → SHA-1.
• 64 / 128 hex chars → SHA-256 / SHA-512.
• Starts with $2a$ / $2b$ / $2y$ → bcrypt.
• Starts with $argon2id$ → Argon2id.
• Starts with $y$ → yescrypt.
• Starts with $6$ / $5$ / $1$ → SHA-512crypt / SHA-256crypt / MD5crypt.
• Format LM:NTLM → pwdump / secretsdump output.
• Base64 charset with == padding → often LDAP {SSHA}, Django or a re-encoded raw digest.

Confidence explanation

Identification is structural inference, never proof. Many algorithms share a length and charset, so results are ranked in words rather than percentages:

Context beats structure: where the hash came from (SAM dump, /etc/shadow, web app database, network capture) usually settles the ambiguity.

Cracking Tools

Hashcat

• Purpose — GPU-accelerated offline password auditing framework.
• Platforms — Windows, Linux, macOS.
• Reference — https://hashcat.net/hashcat/
• Typical use — auditing your own password policy, CTF challenges, forensics on evidence you own.

John the Ripper

• Purpose — long-standing offline password security auditor from Openwall.
• Platforms — Windows, Linux, macOS, BSD.
• Typical use — cross-format hash auditing and format research; the jumbo build adds hundreds of community formats.
• Reference — https://www.openwall.com/john/

Wordlists

A wordlist is simply a candidate password dictionary. Quality beats size: a small, targeted list usually beats a huge generic one.

rockyou.txt

• What it is — a 14M-entry list from the RockYou breach (2009); the de-facto teaching wordlist.
• Educational use — introductory dictionary labs, CTFs, password policy analysis.
• Lab practice — keep it read-only and hash lab passwords with modern KDFs to show why raw MD5/SHA-1 fails.

SecLists

• What it is — curated collection by Daniel Miessler covering passwords, usernames, fuzzing payloads and discovery lists.
• Educational use — targeted labs such as top-500-worst-passwords, plus directory and parameter enumeration.
• Reference — https://github.com/danielmiessler/SecLists

Custom wordlists

• What they are — lists derived from a target's public content: company site, bios, product names, transcripts.
• Educational use — showing how weak-but-common patterns (Season + Year + !, CompanyName123) survive policies.
• Lab practice — generate with tools like cewl on lab domains only, keep results scoped, and destroy them after reporting.

Attack Methods

Documented as a learning aid only.

Common Hash Types

Best Practices

• Prefer long passphrases or a password manager over complexity rules.
• Always store a unique random salt per credential.
• Add a pepper kept outside the database when your threat model needs it.
• Use Argon2id, bcrypt or yescrypt; never raw MD5, SHA-1 or SHA-256.
• Enable MFA so a single leaked credential is not enough.

Interactive Hash Identifier

Paste a hash below to see likely formats, matching rationale and reference commands. Runs fully in your browser.