Hash Algorithm Identifier
Distinguish self-identifying password hashes from ambiguous digest shapes and token-like values.
Self-describing password formats can be recognized with much more confidence than a bare hexadecimal digest. A bare digest is classified by shape, not declared to be a specific algorithm.
How much ambiguity should stay visible?
Copyable classification
The format clues will appear here.
A hash string can reveal a format without revealing an algorithm
Prefix-rich password hashes such as bcrypt and Argon2 carry identifying structure: algorithm family, version or parameters, salt, and encoded output. A bare 64-character hexadecimal string carries far less information. It tells you that 256 bits are being represented, not whether the bytes came from SHA-256, SHA3-256, BLAKE2s, SHA-512/256, random data, or something application-specific.
The distinction matters during migrations and incident work. A confident-looking algorithm label based only on digest length can send debugging in the wrong direction.
Why MD5 and NTLM cannot be separated by 32 hex characters
Both are often written as 32 hexadecimal characters. Many unrelated 128-bit values have the same text shape. Without surrounding metadata—database column meaning, framework settings, source code, protocol context, or a known test vector—the string alone does not prove which algorithm produced it.
For the same reason, 40, 56, 64, 96, and 128 hex characters are described here as digest-size clues rather than definitive SHA labels.
Password-hash prefixes carry more evidence, but parameters still matter
A valid-looking bcrypt string identifies the bcrypt storage format and exposes its cost field. An Argon2 PHC string exposes the variant and memory, time, and parallelism parameters. Recognition still does not answer whether those settings are suitable for current hardware, whether salts were generated correctly, or whether the application verifies passwords safely.
PBKDF2 and scrypt are especially dependent on framework-specific serialization. A visible label can be a strong clue while the exact string grammar remains implementation-specific.
Encoded random bytes can look exactly like a digest
Base64 and Base64URL strings often appear in API keys, nonces, session identifiers, binary digests, and random secrets. When an encoded value has a canonical form, the decoded byte count is a useful clue. It is still only a byte count. Random 32-byte data and a 32-byte hash digest can have the same encoded length.
Security decisions need more than a guessed name
NIST's Secure Hash Standard defines the SHA-1 and SHA-2 digest sizes, while SHA-3 is defined separately. NIST is transitioning away from SHA-1 for remaining applications. For password storage, fast message digests and memory-hard password hashes solve different problems; RFC 9106 documents Argon2 and recommends Argon2id for broadly applicable password-hashing settings.
References: NIST FIPS 180-4, NIST SHA-1 transition guidance, and RFC 9106.