Hash Type Identifier

Introduction

Stored hashes rarely arrive with perfect documentation. They show up in database dumps, LDAP exports, password-migration notes, incident tickets, application logs, and old configuration files, often as one long string with only a few visible clues. Those clues can still matter. A leading $2b$ points toward bcrypt, $argon2id$ points toward Argon2id, {SSHA} points toward an LDAP-style password value, and a leading * plus forty hexadecimal characters often points toward a MySQL password hash shape.

The hard part is knowing which clues are strong and which are only suggestive. Password hashing schemes often store the algorithm marker, salt, cost factor, and encoded digest together because a verifier needs that information later. Plain cryptographic digests are different. A bare 32-character hexadecimal value might be MD5, MD4, NTLM, or another 128-bit digest representation. A 64-character hexadecimal value might fit SHA-256 or SHA3-256. The visible text tells you the storage shape, not the password, original input, product, or security level by itself.

That distinction matters during migrations and audits. A password hash with a self-describing modular crypt string can usually be routed to the matching verifier with less guesswork. A raw digest or checksum may need field names, export notes, database version, account type, or surrounding code before it can be labeled safely. Treating a length-only guess as proof can send a migration down the wrong path or make an incident note sound more certain than the evidence supports.

Four kinds of evidence are useful in practice: explicit markers, tagged wrappers, encoded length, and source context. Markers such as $5$, $6$, $P$, pbkdf2_sha256$, or S: can narrow a family quickly. Length and alphabet checks are weaker because many algorithms share output sizes. Source context remains important because database authentication strings, directory values, password hashes, checksums, tokens, and truncated log fragments can look similar after copying.

Real credential material deserves careful handling even when it is "only a hash." A password hash can let an attacker test guesses offline, and a digest copied from a private workflow may reveal account, file, or system context. Identification should be treated as triage: useful for routing and cleanup, but not a substitute for a trusted verifier or source-system evidence.

How to Use This Tool:

Use the checker when you need to sort copied hash-like values into likely families before a verifier, migration script, or incident note makes final decisions.

1. Paste one value per line in Hash input, or use Browse file / drag and drop for a TXT, LOG, or CSV file under 2 MB. The text area accepts copied log lines as well as already-clean values.
2. Choose Smart cleanup for lines such as hash=..., quoted values, or single hash-like tokens embedded in copied text. Choose Strict raw values when labels and surrounding characters are part of what you need to inspect.
3. Set Collapse duplicates based on the job. Leave it on for unique inventory work. Turn it off when repeated rows from a source export need to remain visible.
4. Check the summary first. For a single row, it shows the likely family or the reason the value is ambiguous, unknown, or in need of cleanup. For several rows, it counts matched, ambiguous, cleanup, and unknown values.
5. Use Show rows to focus the Lookup Table on high-confidence rows, ambiguous rows, or values that need attention. If a row says Cleanup likely, paste only the raw token, switch to Smart cleanup, or check Base64 padding and copy boundaries.
6. Open Triage Brief for a compact summary, Confidence Signal Chart for the distribution of confidence labels, and JSON when another workflow needs the structured result.
7. Use Save history only when local browser snapshots are helpful, and leave Share input in URL off for sensitive values. A shared address can expose short pasted input to anyone who receives it.

After classification, confirm important rows with the system that produced them or with the verifier that will actually check the value.

Interpreting Results:

The Status label is confidence about visible format, not a security rating. A strong bcrypt or Argon2 signal can still use weak cost settings, old parameters, or poor surrounding account controls. A length-only digest may be structurally valid while still being the wrong family for the system you are reviewing.

The Top signal, Candidates, Evidence, and Next step fields should be read together. The top signal is the first routing clue; the evidence explains why it appeared; the next step tells you what outside confirmation is still needed.

Technical Details:

Hash identification is an ordered rule problem. Specific markers are more reliable than generic shape checks, so self-describing password-hash strings, LDAP scheme tags, and database authentication prefixes should be considered before plain hexadecimal or Base64 length tests. A marker can name a storage scheme, while length only says how many encoded bytes may be present.

Rule Core:

Hexadecimal length is easy to count because each byte becomes two hex characters. Base64 is less direct because the encoding works in three-byte groups and uses padding when the final group is short. That is why a Base64-looking value with missing or inconsistent padding can move from a candidate to a cleanup warning.

Modern password hashes are usually better identified by structure than by digest size. Argon2 strings commonly carry a variant, version, memory cost, iteration count, parallelism, salt, and hash. bcrypt strings carry a version marker, cost, salt, and checksum in a compact modular crypt format. PBKDF2 variants often carry the digest family and iteration count. Those embedded fields are part of what a verifier needs, so removing them can make a real password hash unusable.

Directory and database formats add another source of clues. LDAP-style scheme tags such as {SHA}, {SSHA}, and {SMD5} name how the following Base64 value should be interpreted. PostgreSQL MD5 authentication strings and MySQL 4.1-style password hashes have product-specific wrappers. These clues help route records, but they do not make old or legacy methods safe.

A label in copied text should be handled carefully. If a line begins with SHA256: and the remaining value is 64 hexadecimal characters, the label is useful source context, but the normalized token still has the same visible shape as SHA-256 and SHA3-256. The safer record is "64-hex digest with a SHA256 source label" until the producing system or verifier confirms the algorithm.

Privacy and Security Notes:

The checker analyzes pasted text and supported local files in the browser. It does not need to upload hash input to classify rows. Privacy can still be lost through user actions, so handle exported tables, copied rows, downloaded JSON, saved browser history, and shared URLs as credential-adjacent material.

• Local history: when Save history is on, recent lookup snapshots are kept in the same browser and can include the original pasted text.
• Shared URLs: when Share input in URL is on, short input can appear in the address bar and in anything that stores or forwards that address.
• Exports: CSV, DOCX, image, and JSON downloads can preserve normalized values, evidence, candidate names, and copied source text.
• Security meaning: identifying a format does not verify a password, rate password strength, crack a hash, or prove that a stored value is safe to keep.

Worked Examples:

FAQ:

Glossary:

Digest

A fixed-size value produced by a hash function from an input.

Salt

Random or unique data stored with a password hash so equal passwords do not produce equal stored values.

Cost factor

A work setting, iteration count, memory setting, or related parameter that changes how expensive verification is.

Modular crypt

A password-hash string style that uses $-separated markers and fields to carry the scheme and verification data.

Scheme tag

A visible wrapper such as {SSHA} that names how a directory password value should be interpreted.

Verifier

The password-hash or authentication code path that checks whether a supplied password matches a stored value.

References:

• NIST SP 800-63B: Authentication and Authenticator Management, National Institute of Standards and Technology, August 2025.
• RFC 9106: Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications, RFC Editor, September 2021.
• Password Storage Cheat Sheet, OWASP Cheat Sheet Series.
• What are RFC 2307 hashed user passwords?, OpenLDAP FAQ-O-Matic.
• PostgreSQL Password Authentication, PostgreSQL documentation.