A hash digest carries no metadata about which algorithm produced it — it's just a fixed-length string of hex or base64 characters — but the length itself is usually diagnostic, because each algorithm has a fixed output size. 32 hex characters (128 bits) is almost always MD5. 40 hex characters (160 bits) is SHA-1. 64 hex characters (256 bits) is SHA-256, and 128 hex characters (512 bits) is SHA-512. Length alone doesn't prove the algorithm — a coincidental string of the right length and character set will match the same pattern — but it's a strong first signal.
The distinction matters because MD5 and SHA-1 are both cryptographically broken for security purposes. MD5 has practical collision attacks demonstrated since 2004 and is considered fully broken for anything requiring collision resistance — two different inputs can be deliberately constructed to produce the identical hash. SHA-1 was formally broken by a practical collision (the 'SHAttered' attack) in 2017, published jointly by Google and CWI Amsterdam. Neither should appear in new password-storage or digital-signature code; finding one in an existing system is worth flagging for migration.
bcrypt and similar password-hashing schemes (Argon2, scrypt, PBKDF2) look structurally different from a bare cryptographic hash — bcrypt output starts with a version prefix like $2b$ followed by a cost factor and then the salt and hash concatenated, encoded in a base64 variant. This structure exists specifically because password hashing needs a built-in, tunable work factor that general-purpose hash functions don't have; using a bare SHA-256 to hash passwords, even though SHA-256 itself isn't broken, is a design mistake because it has no built-in slowness against brute-force guessing.
This identifier checks the input's length and character set against every algorithm's known output format, ranks the most likely match, and flags MD5, SHA-1, and NTLM explicitly as unsuitable for any new security-relevant use — while noting that plenty of legitimate use cases (checksums, cache keys, non-security deduplication) still use MD5 for its speed, where the collision weakness is irrelevant.
Edge cases worth knowing
- A 32-character hex string used as a non-cryptographic checksum
- MD5 remains extremely common for file integrity checks, ETags, and cache keys — contexts where collision resistance doesn't matter and speed does. This identifier flags MD5 as broken specifically for security contexts (passwords, signatures, tamper-detection) rather than for every possible use.
- A bcrypt hash with an unusually high or low cost factor
- The cost factor embedded in a bcrypt string ($2b$12$... — the 12) determines how many rounds of key derivation it uses; higher is slower and more resistant to brute force. A cost factor left at an old default (or set unreasonably low for 'performance') is worth flagging even though the format itself is correct.
- A string that happens to be 64 hex characters but isn't a hash at all
- A random 256-bit key rendered as hex is indistinguishable from a SHA-256 digest by format alone. This identifier reports what the string is consistent with, not a certainty — the actual source context is what tells you which it is.
Common mistakes
- Using unsalted MD5 or SHA-1 to store user passwords, which are both fast to compute and vulnerable to precomputed rainbow-table lookups.
- Treating 'it's SHA-256, so it's secure' as sufficient for password storage — SHA-256 is cryptographically sound but has no built-in work factor, making it far too fast for safe password hashing without a dedicated KDF wrapper.
- Confusing a hash (one-way, irreversible) with encryption (two-way, reversible with a key) and expecting to 'decrypt' a password hash.
- Migrating away from MD5/SHA-1 for file integrity but leaving them in place for authentication tokens or signatures, where the security stakes are much higher.