Hash Identifier

Two classes of hash, two levels of certainty

Modern password formats are self-describing. A value that starts with $2b$, $argon2id$ or $y$ announces its own scheme, and the rest of the string is split into fields by dollar signs: parameters, salt and digest. Identification there is not a guess, it is reading. That is exactly why the crypt(3) convention was designed this way: to verify a password, the system needs to know which function and which parameters produced the hash.

Bare digests are the opposite. A SHA-256 is just the output of the function, 32 bytes with no metadata, written as 64 hexadecimal characters. Nothing in those 64 characters distinguishes a SHA-256 from a Keccak-256 or a BLAKE2s-256. So the tool changes language in that case: instead of asserting, it ranks by observed frequency and explains each position, making clear that the final call depends on where the data came from.

• With a prefix: the format is read straight from the string, with parameters and salt separated.
• Without a prefix: candidates ranked by probability, each with the reason for its position.
• Alphabet and length are shown as facts, not as a conclusion.
• When the input is not a hash, the tool says what it actually is.

What the hash parameters say about the system

Identifying the algorithm is half the information. The other half is the parameters, and they are visible inside the hash itself. In bcrypt, the number between dollar signs is the cost factor: 12 means 2 to the power of 12, that is 4096 iterations of the derivation function. In Argon2, m is memory in KiB, t is the number of passes and p is parallelism, the three parameters that define how much hardware an attack would need. In PBKDF2, sha256crypt and sha512crypt, the iteration field says the same thing on a different scale.

This changes how an audit reads. A bcrypt with cost 4 and a bcrypt with cost 14 are the same algorithm with orders of magnitude between their attack costs. An Argon2id with 64 MiB of memory and one with 8 MiB likewise. Seeing those numbers next to the format name is what turns identification into diagnosis, and it is why the tool extracts and shows each of them instead of stopping at the name.

What identification by inspection cannot solve

No identification tool, this one included, can separate algorithms that produce the same output size over the same alphabet. Truncation misleads too: a SHA-256 cut to 32 characters starts to look like MD5, and nothing in the string reveals the cut. In the same way, a hash whose salt lives in another database column arrives here as a bare digest, with no sign that a salt exists anywhere.

The origin of the data resolves almost all of those cases, and no inspection replaces it. A value exported from a domain controller is NTLM even though it looks like MD5. A value from the password column of an old CMS is usually MD5 or phpass, depending on the version. A value in an integrity file is almost always SHA-256. That is why the output here is a ranked hypothesis with the reasoning on display, for you to confirm against what you know about the source, and never a verdict.

• Truncated digests imitate the length of other algorithms.
• A salt stored in a separate column never shows up in the value.
• Encoding (base64, uppercase hex) changes the look without changing the algorithm.
• The origin of the data usually beats any format heuristic.