CRYPT(5)

💖 CRYPT — storage format for hashed passphrases and available hashing methods 💖

okay bestie, pull up a chair, we're doing crypt(5) and honestly? it's giving ✨foundational✨. this is the page about how your passphrase gets turned into a weird little string of $ and base64 nonsense that lives in shadow(5) and judges you silently forever. let's get into it 🫶

---

✨ DESCRIPTION ✨

okay so first thing, super important, no cap: the hashing methods that crypt(3) implements are only designed to chew on user passphrases for storage and authentication. that's it. that's their whole job. do not try to use them as general-purpose cryptographic hashes, because they are simply not built for that and it would be a whole thing 😭

also, and this is the part everyone wants to skip but shouldn't: passphrase hashing is not a replacement for a strong passphrase. if an attacker gets their hands on your hashed passphrases, they can absolutely sit there and guess and check cleartext passphrases. that's just how it is, ngl. but — with a strong hashing method, all that guessing gets so slow that a genuinely strong passphrase is basically out of reach. the math just doesn't math for them anymore 💅

most of the hashing methods use a "salt" to perturb the hash function, so the same passphrase can produce like a million different possible hashes. newer methods accept longer salt strings. the salt should be picked at random for each user. salt is out here defeating attacks left and right:

1. you can't hash a passphrase once and then test it against every account's stored hash — the hash calculation has to be redone for each and every account. no shortcuts, sorry not sorry 🚫
2. you can't tell whether two accounts use the same passphrase without successfully guessing one of the phrases. mystery maintained ✨
3. tables of precalculated hashes of commonly used passphrases would need an entry for every possible salt, which makes them impractically, hilariously large. imagine the file size. imagine it 💀

and most of these methods are also deliberately engineered to be slow. iconic behaviour honestly. they use many iterations of an underlying cryptographic primitive to crank up the cost of each guess. the newer methods let you adjust the number of iterations using the "processing cost" parameter to crypt_gensalt(3). for memory-hard methods like yescrypt, this parameter also adjusts how much memory is needed to compute a hash. having it configurable means password-guessing attacks stay slow and expensive as hardware keeps getting better — the vibe check on your GPU farm keeps failing, and that's the point 👑

---

🌈 FORMAT OF HASHED PASSPHRASES 🌈

every hashing method crypt(3) supports produces a hashed passphrase made of four components: prefix, options, salt, and hash.

• the prefix controls which hashing method gets used, and it's the exact string you hand to crypt_gensalt(3) to select that method
• the contents of options, salt, and hash are up to the method
• depending on the method, the prefix and options components may be totally empty. empty is a valid vibe sometimes

the setting argument to crypt(3) must begin with the first three components of a valid hashed passphrase. anything after that? ignored, bestie. not even looked at. this is what makes authentication so easy:

1. hash the input passphrase using the stored hashed passphrase as the setting
2. compare the result to the stored hashed passphrase

that's it. that's the whole trick 🎀

hashed passphrases are always entirely printable ASCII, and they do not contain any whitespace or the characters ':', ';', '*', '!', or '\'. (those characters are delimiters and special markers in the passwd(5) and shadow(5) files, so they're off-limits, periodt.)

the syntax of each component is up to the hashing method. '$' characters usually delimit components, and the salt and hash are usually encoded as numerals in base 64. the details of this base-64 encoding vary among hashing methods — the common "base64" encoding specified by RFC 4648 is usually not used. rude? maybe. but that's the lore 🦋

---

👑 AVAILABLE HASHING METHODS 👑

here's the full list of every hashing method crypt(3) supports, roughly in decreasing order of strength. heads up: many of the older methods are now considered too weak to use for new passphrases, so don't be out here picking the cute retro one 💀

the hashed passphrase format is expressed with extended regular expressions (see regex(7)) and does not show the division into prefix, options, salt, and hash.

---

🧂 yescrypt

yescrypt is a scalable passphrase hashing scheme designed by Solaris Designer... okay no wait, by Solar Designer — and it's based on Colin Percival's scrypt. while yescrypt's strength against password guessing attacks comes from its algorithm design, its cryptographic security is guaranteed by its use of SHA-256 on the outer layer. the SHA-256 hash function has been published by NIST in FIPS PUB 180-2 (and its subsequent revisions such as FIPS PUB 180-4) and by the IETF as RFC 4634 (and subsequently RFC 6234).

Recommended for new hashes. like, genuinely, this is the one ✨

• Prefix — "$y$"
• Hashed passphrase format

\$y\$[./A-Za-z0-9]+\$[./A-Za-z0-9]{,86}\$[./A-Za-z0-9]{43}

• Maximum passphrase length — unlimited ♾️
• Hash size — 256 bits
• Salt size — up to 512 (128+ recommended) bits
• Processing cost parameter — 1 to 11 (logarithmic, also affects memory usage)

---

🇷🇺 gost-yescrypt

gost-yescrypt takes the output from yescrypt and uses it as an input message to HMAC with the GOST R 34.11-2012 (Streebog) hash function with a 256-bit digest. so basically yescrypt's cryptographic properties get superseded by those of the GOST hash function. this method is useful in applications that need modern passphrase hashing but have to rely on GOST algorithms. the GOST R 34.11-2012 (Streebog) hash function has been published by the IETF as RFC 6986.

Acceptable for new hashes where required.

• Prefix — "$gy$"
• Hashed passphrase format

\$gy\$[./A-Za-z0-9]+\$[./A-Za-z0-9]{,86}\$[./A-Za-z0-9]{43}

• Maximum passphrase length — unlimited ♾️
• Hash size — 256 bits
• Salt size — up to 512 (128+ recommended) bits
• Processing cost parameter — 1 to 11 (logarithmic, also affects memory usage)

---

🇨🇳 sm3-yescrypt

sm3-yescrypt takes the output from yescrypt as an input message to HMAC with the ShangMi 3 hash function with a 256-bit digest. so yescrypt's cryptographic properties are superseded by those of the ShangMi 3 hash function here. this one's useful in applications that need modern passphrase hashing but have to rely on algorithms approved by the Chinese Office of State Commercial Cryptography Administration (OSCCA). the ShangMi 3 hash function has been published in Part 3: "Dedicated hash-functions" of the ISO/IEC 10118-3:2018.

Acceptable for new hashes where required.

• Prefix — "$sm3y$"
• Hashed passphrase format

\$sm3y\$[./A-Za-z0-9]+\$[./A-Za-z0-9]{,86}\$[./A-Za-z0-9]{43}

• Maximum passphrase length — unlimited ♾️
• Hash size — 256 bits
• Salt size — up to 512 (128+ recommended) bits
• Processing cost parameter — 1 to 11 (logarithmic, also affects memory usage)

---

🧠 scrypt

scrypt is a password-based key derivation function created by Colin Percival, originally for the Tarsnap online backup service. the algorithm was specifically designed to make large-scale custom hardware attacks costly to perform, by requiring large amounts of memory. in 2016, the scrypt algorithm was published by IETF as RFC 7914. memory-hungry on purpose, and we love that for it 🫶

• Prefix — "$7$"
• Hashed passphrase format

\$7\$[./A-Za-z0-9]{11,97}\$[./A-Za-z0-9]{43}

• Maximum passphrase length — unlimited ♾️
• Hash size — 256 bits
• Salt size — up to 512 (128+ recommended) bits
• Processing cost parameter — 6 to 11 (logarithmic, also affects memory usage)

---

🐡 bcrypt

a hash based on the Blowfish block cipher, modified to have an extra-expensive key schedule. originally developed by Niels Provos and David Mazieres for OpenBSD, and also supported on recent versions of FreeBSD and NetBSD, on Solaris 10 and newer, and on several GNU/*/Linux distributions. little fish, big opinions 🐠

• Prefix — "$2b$"
• Hashed passphrase format

\$2[abxy]\$[0-9]{2}\$[./A-Za-z0-9]{53}

• Maximum passphrase length — 72 characters
• Hash size — 184 bits
• Salt size — 128 bits
• Processing cost parameter — 4 to 31 (logarithmic)

the alternative prefix "$2y$" is equivalent to "$2b$". it exists for historical reasons only, bestie. the alternative prefixes "$2a$" and "$2x$" provide bug-compatibility with crypt_blowfish 1.0.4 and earlier, which incorrectly processed characters with the 8th bit set. yes, they shipped a bug, yes, we have to carry it around forever 🙈

---

🔐 sha512crypt

a hash based on SHA-2 with 512-bit output, originally developed by Ulrich Drepper for GNU libc. supported on Linux but not common elsewhere. Acceptable for new hashes. but heads up: the default processing cost parameter is 5000, which is too low for modern hardware. it's giving 2011, honestly 💀

• Prefix — "$6$"
• Hashed passphrase format

\$6\$(rounds=[1-9][0-9]+\$)?[^$:\n]{1,16}\$[./0-9A-Za-z]{86}

• Maximum passphrase length — unlimited ♾️
• Hash size — 512 bits
• Salt size — 6 to 96 bits
• Processing cost parameter — 1000 to 999,999,999

---

🔏 sha256crypt

a hash based on SHA-2 with 256-bit output, originally developed by Ulrich Drepper for GNU libc. supported on Linux but not common elsewhere. Acceptable for new hashes. same warning though: the default processing cost parameter is 5000, which is too low for modern hardware. bump that number up, bestie 🎀

• Prefix — "$5$"
• Hashed passphrase format

\$5\$(rounds=[1-9][0-9]+\$)?[^$:\n]{1,16}\$[./0-9A-Za-z]{43}

• Maximum passphrase length — unlimited ♾️
• Hash size — 256 bits
• Salt size — 6 to 96 bits
• Processing cost parameter — 1000 to 999,999,999

---

🀄 sm3crypt

a hash based on the ShangMi 3 hash function with 256-bit output, that uses the same design as sha256crypt and/or sha512crypt. supported on EulerOS, Kylin, openEuler, and openKylin, but not common elsewhere. Acceptable for new hashes where required. and yeah, same deal as its sha-crypt siblings: the default processing cost parameter is 5000, which is too low for modern hardware.

• Prefix — "$sm3$"
• Hashed passphrase format

\$sm3\$(rounds=[1-9][0-9]+\$)?[^$:\n]{1,16}\$[./0-9A-Za-z]{86}

• Maximum passphrase length — unlimited ♾️
• Hash size — 256 bits
• Salt size — 6 to 96 bits
• Processing cost parameter — 1000 to 999,999,999

---

🦴 sha1crypt

a hash based on HMAC-SHA1. originally developed by Simon Gerraty for NetBSD. it's not as weak as the DES-based hashes below, but SHA-1 is so cheap on modern hardware that it should not be used for new hashes. like, it's not the worst, but it's not the moment either 🥲

• Prefix — "$sha1"
• Hashed passphrase format

\$sha1\$[1-9][0-9]+\$[./0-9A-Za-z]{1,64}\$[./0-9A-Za-z]{8,64}[./0-9A-Za-z]{32}

• Maximum passphrase length — unlimited ♾️
• Hash size — 160 bits
• Salt size — 6 to 384 bits
• Processing cost parameter — 4 to 4,294,967,295

---

☀️ SunMD5

a hash based on the MD5 algorithm, originally developed by Alec David Muffett for Solaris. not adopted elsewhere, to our knowledge. and same energy as sha1crypt: it's not as weak as the DES-based hashes below, but MD5 is so cheap on modern hardware that it should not be used for new hashes. it's a relic, bestie, put it back in the museum 🏛️

• Prefix — "$md5"
• Hashed passphrase format

\$md5(,rounds=[1-9][0-9]+)?\$[./0-9A-Za-z]{8}\${1,2}[./0-9A-Za-z]{22}

• Maximum passphrase length — unlimited ♾️
• Hash size — 128 bits
• Salt size — 48 bits
• Processing cost parameter — 4096 to 4,294,963,199

---

🌸 md5crypt 🌸

Okay bestie, this one's a hash built on the MD5 algorithm, originally cooked up by Poul-Henning Kamp for FreeBSD. It works on most free Unixes and on newer versions of Solaris. It's not as weak as the DES-based ones chilling below, but ngl, MD5 is so cheap on modern hardware that you should not be using this for new hashes. Periodt.

And the processing cost? Not adjustable. It's giving fixed. 🙈

• Prefix — "$1$"
• Hashed passphrase format — \$1\$[^$:\n]{1,8}\$[./0-9A-Za-z]{22}
• Maximum passphrase length — unlimited ✨
• Hash size — 128 bits
• Salt size — 6 to 48 bits
• Processing cost parameter — 1000

---

🦋 bsdicrypt (BSDI extended DES) 🦋

So this one is an extension of traditional DES that goes ahead and eliminates the length limit, increases the salt size, and makes the time cost tunable. Main character energy fr. It originates with BSDI BSD/OS, and it's also available on at least NetBSD, OpenBSD, and FreeBSD, all thanks to David Burren's FreeSec library. It's much better than traditional DES and bigcrypt, but still — should not be used for new hashes. 💀

• Prefix — "_"
• Hashed passphrase format — _[./0-9A-Za-z]{19}
• Maximum passphrase length — unlimited (ignores 8th bit)
• Hash size — 64 bits
• Effective key size — up to 56 bits
• Salt size — 24 bits
• Processing cost parameter — 1 to 16,777,215 (must be odd)

---

💀 descrypt (Traditional DES) 💀

The OG hashing method from Unix V7, based on the DES block cipher. And here's the tea: because DES is cheap on modern hardware, because there are only 4096 possible salts and 2**56 distinct passphrases (which it truncates to 8 characters, btw), it is feasible to discover any passphrase hashed with this method. Like, any of them. 😭

Only use this if you absolutely have to generate hashes that will work on an old operating system that supports nothing else. And I mean nothing else.

• Prefix — "" (empty string)
• Hashed passphrase format — [./0-9A-Za-z]{13}
• Maximum passphrase length — 8 characters (ignores 8th bit)
• Hash size — 64 bits
• Effective key size — up to 56 bits
• Salt size — 12 bits
• Processing cost parameter — 25

---

🎀 bigcrypt 🎀

A weak extension of traditional DES that shows up on some commercial Unixes. All it does — literally all — is raise the length limit from 8 to 128 characters. And it does it in a crude way that lets attackers guess chunks of a long passphrase separately and in parallel, which may make guessing even easier than for traditional DES above. Not it. 🚫

Should not be used for new hashes, bestie.

• Prefix — "" (empty string)
• Hashed passphrase format — [./0-9A-Za-z]{13,178}
• Maximum passphrase length — 128 characters (ignores 8th bit)
• Hash size — up to 1024 bits
• Effective key size — up to 56 bits
• Salt size — 12 bits
• Processing cost parameter — 25

---

🙈 NT 🙈

The hashing method used for network authentication in some versions of the SMB/CIFS protocol. Available, for cross-compatibility's sake, on FreeBSD. Based on MD4. It has no salt and no tunable cost parameter. It is so weak that almost any human-chosen passphrase hashed with this method is guessable. Like, your cat's name? Guessed. Your birthday? Guessed. 💀

Only use this if you absolutely have to generate hashes that will work on an old operating system that supports nothing else. Same rule as above, no exceptions.

• Prefix — "$3$"
• Hashed passphrase format — \$3\$\$[0-9a-f]{32}
• Maximum passphrase length — unlimited
• Hash size — 256 bits
• Salt size — 0 bits
• Processing cost parameter — 1

---

⭐ SEE ALSO ⭐

• crypt(3)
• crypt_gensalt(3)
• getpwent(3)
• passwd(5)
• shadow(5)
• pam(8)

Niels Provos and David Mazieres, “A Future-Adaptable Password Scheme”, Proceedings of the 1999 USENIX Annual Technical Conference, https://www.usenix.org/events/usenix99/provos.html, June 1999.

Robert Morris and Ken Thompson, “Password Security: A Case History”, Communications of the ACM, 11, 22, http://wolfram.schneider.org/bsd/7thEdManVol2/password/password.pdf, 1979.

---

And that's the whole page, bestie!! 🫶 Go forth and pick a hashing method that isn't from 1979, okay? Your future self will thank you. 💖

This page is brought to you by the Openwall Project — dated March 27, 2024 — and it lives under the name CRYPT(5). Stan them, they did the work. ✨👑