Hash Format Identifier

About the Hash Format Identifier

Passwords should never be stored as they are typed, but what an application stores instead varies enormously: a bcrypt string, an Argon2 record, a salted SHA-512 line from /etc/shadow, a bare 32-digit MD5, a {SSHA} value from a directory, a Django or Flask format. This page reads the shape of a pasted hash or stored password — its prefix, its length and alphabet, and the numbers written into it — and says which format it most likely is, how sure it is, what the string tells about its cost and salt, and whether the scheme suits password storage by the figures OWASP and libxcrypt publish.

It is meant for checking your own systems: planning a move from MD5, SHA-1 or an old Unix crypt to Argon2id, auditing a user table or a directory before a migration, or understanding a string in a config file or backup. Paste one value, or a whole list with one per line, and you get a count by verdict and a line-by-line table. It never reverses a hash, never looks one up and never tries a password; the text stays in your browser.

Without a pass the result is a free preview: the format, how sure the page is, the verdict for passwords, the parts of the string and the counts of a list in full, with the first half of the settings, the reasons, the advice and the line table. The whole result, and copying or downloading the report, unlock with a Pro pass.

Common uses

• Auditing an application’s user table before a migration: which schemes are in use, and how many accounts each.
• Checking what Django, Flask, Spring Security, ASP.NET Core Identity, WordPress, PostgreSQL, MySQL or a directory server stores, and whether its settings still meet OWASP’s figures.
• Finding Apache htpasswd entries, directory passwords or system accounts that still use MD5-crypt, {SHA} or plain text.
• Working out what a string in a config file, a backup or a support ticket is before deciding whether it is a secret.

How the page tells formats apart

• Prefixes are the surest sign: $2b$ bcrypt, $argon2id$ Argon2, $6$ SHA-512-crypt, $y$ yescrypt, $P$ phpass, {SSHA} and the other bracketed names of LDAP and Spring Security, pbkdf2_sha256$ Django, scrypt: Flask.
• Length and alphabet decide the rest. A bcrypt hash is exactly 60 characters; a SHA-512-crypt checksum is 86; an unsalted digest is 32, 40, 56, 64, 96 or 128 hex digits.
• Parameters are read out of the string: a bcrypt cost, Argon2 memory and iterations, PBKDF2 iterations, scrypt N, r and p, the salt length.
• Certainty says how much of that was needed: certain when a prefix and a valid layout agree, likely for the usual reading of a bare digest, possible for the others that share its length.

What the verdicts mean

The ratings follow the OWASP Password Storage Cheat Sheet and libxcrypt’s crypt(5).

• Recommended: Argon2id with at least 19 MiB of memory, 2 iterations and 1 lane (or an equal setting), and yescrypt on Linux.
• Acceptable: scrypt, bcrypt and PBKDF2 at or above OWASP’s settings, and SHA-crypt with many rounds. OWASP names scrypt as the fallback, bcrypt for legacy systems and PBKDF2 where FIPS-140 compliance is required.
• Raise the settings: the right kind of function with a cost below the published figures.
• Replace this scheme: single rounds of MD5, SHA-1 or SHA-2, salted or not, and the old crypt, phpass, LDAP, MySQL and Windows formats.
• Not a password hash: UUIDs, tokens, integrity values and fingerprints.

The figures used

• bcrypt: a work factor of at least 10.
• PBKDF2: 600,000 iterations with HMAC-SHA-256, 220,000 with HMAC-SHA-512, 1,400,000 with HMAC-SHA-1 (legacy only).
• Argon2id: 47,104 KiB with 1 iteration, 19,456 KiB with 2, 12,288 KiB with 3, 9,216 KiB with 4 or 7,168 KiB with 5, one lane. Argon2i counts only from 3 iterations.
• scrypt: N = 2^17 with p = 1, 2^16 with p = 2, 2^15 with p = 3, 2^14 with p = 5 or 2^13 with p = 10, all with r = 8; a larger r counts as a proportionally larger N.
• SHA-crypt: crypt(5) calls its default of 5,000 rounds “too low for modern hardware” and gives no target above it.

These are guidance, and guidance moves: check the OWASP page for the figures in force before you decide.

Moving away from a weak scheme

You cannot turn a hash back into a password, so a move happens as users sign in. OWASP describes the options:

• Rehash at the next sign-in: verify the password against the old hash, then store a new hash made with the stronger scheme. Old hashes stay in the database until the user signs in.
• Layer the existing hash: use the stored hash as the input of a stronger function, for example bcrypt around an MD5, so every account is protected at once, then swap it for a plain hash at the next sign-in. Layering avoids needing the original passwords but can make the hashes easier to crack.
• Expire dormant accounts: delete the hashes of users inactive for a long time, which is secure but unfriendly and can look like a breach.

Whichever you choose, new hashes should use Argon2id from the first day.

What the page never does

It never reverses a hash, never looks one up in a table or on the web, and never tests a password. It makes no network request at all. The reports shorten every hash to its first ten and last three characters, and a line that could not be read is reported only as a length, because it may be a password in plain text.

Limitations

• A bare digest’s length is shared by several algorithms (32 hex digits can be MD5, NTLM, MD4 or LM), so the page lists them and names the usual one; it cannot know which was used.
• It reads the string, not the system around it. A keyed hash (HMAC) or a hash with a secret pepper looks like a plain digest, and nothing in a string shows whether a pepper exists.
• Formats it does not know — custom schemes, encrypted passwords, hashes of other products — are reported as not recognised, with a note on what the text looks like.
• A rating judges the scheme and the settings written in the string, not the passwords behind it and not the code that checks them.
• A name in braces that Spring Security or an LDAP server writes in front of a value this page cannot read is named but not rated.
• Lines are read up to 4,096 characters each, and a list up to 5,000 lines or 2,000,000 characters.

Privacy

On this device: nothing is sent

The text you paste is read in this tab by the page’s own code. Nothing is sent, stored or looked up, and the page keeps working offline. The report you copy or download is made in this tab too, with each hash shortened.