identification

Overview

Before you can work with a hash you have found in a CTF challenge, you must figure out what kind of hash it is. The algorithm that produced a digest determines how it can be analyzed. Since all hex-encoded hashes look like meaningless strings, hash identification relies on structural clues: length, character set, and format markers. This lesson teaches you to read those clues in a safe lab setting.

Learning objectives

• Explain why identifying the hash type is the first step.
• Use output length (in hex characters) to narrow down common algorithms.
• Recognize format markers such as the modular crypt $id$ prefix.
• Understand why length alone can be ambiguous.

Core concept

A raw hash is usually presented as a hexadecimal string, where each byte of the digest becomes two hex characters (0-9, a-f). Because the output length is fixed per algorithm, the number of hex characters is a strong first hint about which function produced it. Many password-storage formats add an explicit prefix that names the algorithm outright, which removes the guesswork entirely.

Identification is a process of elimination, not certainty: several algorithms share the same output length, so length narrows the field but rarely gives a definitive answer on its own.

How it works

The output size of a hash is fixed, and each byte is two hex characters, so bit-length divided by four gives the hex-character count. Common raw digests:

• MD5 — 128-bit output, 32 hex characters.
• SHA-1 — 160-bit output, 40 hex characters.
• SHA-224 — 224-bit output, 56 hex characters.
• SHA-256 — 256-bit output, 64 hex characters.
• SHA-384 — 384-bit output, 96 hex characters.
• SHA-512 — 512-bit output, 128 hex characters.

Length is ambiguous because different algorithms can share a size. For example, an NTLM hash (used by Windows) is also 32 hex characters, exactly like MD5 — so a 32-character hex string could be either, and only context (where you found it) or cracking behavior distinguishes them.

Many password hashes avoid this ambiguity by using the modular crypt format, a self-describing string that begins with a $id$ marker and packs the algorithm, parameters, salt, and digest together, separated by $:

• $1$ — MD5-crypt
• $2a$ / $2b$ / $2y$ — bcrypt (the number after is the cost factor)
• $5$ — SHA-256-crypt
• $6$ — SHA-512-crypt
• $argon2id$ — Argon2id

So a string beginning $2b$12$... is immediately recognizable as bcrypt with cost 12 — no guessing needed. Automated tools (such as hash-identifying utilities) apply exactly these rules — length plus format patterns — to suggest candidate types, but they present a list of possibilities, and you confirm the real type from context.

Practical example

You extract three strings from an isolated practice challenge and identify them by structure:

5f4dcc3b5aa765d61d8327deb882cf99         -> 32 hex chars  -> MD5 (or NTLM — context decides)
aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d -> 40 hex chars  -> SHA-1
$2b$12$abcdefghijklmnopqrstuv...          -> $2b$ prefix   -> bcrypt, cost 12

The first is 32 hex characters, so MD5 is the leading candidate — but because NTLM shares that length, you note both and let context or a cracking tool decide. The second is unambiguously 40 hex characters — SHA-1. The third needs no counting at all: the $2b$ marker names bcrypt directly, and the 12 tells you its cost factor. Reading the format first saved you from treating a slow, salted password hash as if it were a raw digest.

Cybersecurity relevance

Correct identification drives every next decision. Attempting to analyze a bcrypt hash as though it were raw MD5 wastes effort and fails, because the two are handled completely differently. In defensive work, spotting weak or fast hashes (like unsalted MD5) in a password store is a finding in itself: it tells you the storage scheme is inadequate and passwords are at elevated risk if the database leaks. Recognizing the modular crypt prefixes also lets a reviewer confirm at a glance whether an application uses a proper slow password hash (bcrypt, Argon2) or an unsuitable fast one.

Common mistakes

• Trusting length alone — a 32-character hex string could be MD5 or NTLM; confirm with context.
• Ignoring format prefixes and treating a $...$ modular-crypt string as a raw digest.
• Assuming a single tool answer is definitive — identifiers list candidates; you verify the real type.
• Overlooking encoding — some hashes are shown in Base64 rather than hex, which changes the length and character set you expect.

Key takeaways

• Identification is the first step because the algorithm determines how a hash can be handled.
• Hex-character count is the primary length clue: MD5 = 32, SHA-1 = 40, SHA-256 = 64, SHA-512 = 128.
• Length is ambiguous (MD5 and NTLM are both 32 hex chars); use context to disambiguate.
• Modular crypt prefixes ($2b$ bcrypt, $5$/$6$ SHA-crypt, $argon2id$) name the algorithm and parameters directly.

Check your understanding

• How many hex characters does a SHA-256 digest have, and how do you derive that from its bit length?
• Why can't you always tell MD5 from NTLM by length alone, and what resolves the ambiguity?