Read crypt(5) Hashes: yescrypt, Salts and Legacy Formats

Someone hands you a string starting with $y$ or $6$ and asks if it is safe to drop into a password file. This guide shows you how to generate a crypt(5) hash, read its method and salt, and know what is safe to store. The examples use libxcrypt 4.4.36-4build1 and mkpasswd from whois 5.5.22.

• Time: about fifteen minutes.
• You need: a shell and the mkpasswd command.
• What it will not touch: /etc/shadow, any account, or anything needing elevated privileges.
• Passphrases: use a test one only. A passphrase typed as a command argument can leak through shell history or process listings, so the examples read it from standard input.

1. Check the installed tools

Confirm which command will run and which package supplied it. This is an ordinary read-only check:

$ command -v mkpasswd
/usr/bin/mkpasswd
$ dpkg-query -W -f='${Package} ${Version}\n' libcrypt1:amd64 whois
libcrypt1 1:4.4.36-4build1
whois 5.5.22
$ mkpasswd --version
mkpasswd 5.5.22

The package names matter because mkpasswd is a front end to the system's crypt(3) implementation. The list of methods belongs to that implementation, not to every Unix system.

2. Generate a hash with a random salt

Ask mkpasswd to read a test passphrase from standard input and use yescrypt:

$ printf '%s\n' 'Example-passphrase-2026' | mkpasswd --stdin --method=yescrypt
$y$j9T$zXgUWistxAten1xLbcNcR1$CkOgUvmlrZO0/XuHoj8lr1r.PKjy5JRq2IUly9vbe/9

Your result will differ. With no salt supplied, this version of mkpasswd generates one. Run the same command twice and compare the complete lines:

$ printf '%s\n' 'Example-passphrase-2026' | mkpasswd --stdin --method=yescrypt
$y$j9T$another-salt-value$another-hash-value

Different output is not a failure. A random salt is meant to make identical passphrases store as different strings.

At login, the verifier takes the stored string as the setting. It hashes the supplied passphrase with the same method and salt, then compares the results. It never compares your plaintext with a reversible encrypted copy.

3. Read the four parts of the stored string

A crypt(5) result holds a method prefix, optional options, a salt and the hash. The separators and exact grammar belong to the method. In the yescrypt example the dollar signs show the shape:

$y$j9T$zXgUWistxAten1xLbcNcR1$CkOgUvmlrZO0/XuHoj8lr1r.PKjy5JRq2IUly9vbe/9
  |  |                         |                              |
  |  |                         |                              hash
  |  |                         salt and method-specific data
  |  method-specific options
  method prefix

• $y$ is the prefix. It selects yescrypt.
• j9T is not yours to edit. It encodes method-specific cost information, so leave it alone.
• Salt and hash use the method's own alphabet. The lengths are defined by the method too, and are not necessarily RFC 4648 base64.

All valid results are printable ASCII. They exclude whitespace and characters such as :, ;, *, ! and backslash. That lets the result fit the password field used by shadow(5). It does not make an arbitrary string a valid hash.

4. Choose a method, not a legacy trap

List the methods available on this machine:

$ mkpasswd --method=help
Available methods:
yescrypt        Yescrypt
gost-yescrypt   GOST Yescrypt
scrypt          scrypt
bcrypt          bcrypt
bcrypt-a        bcrypt (obsolete $2a$ version)
sha512crypt     SHA-512
sha256crypt     SHA-256
sunmd5          SunMD5
md5crypt        MD5
bsdicrypt       BSDI extended DES-based crypt(3)
descrypt        standard 56 bit DES-based crypt(3)
nt              NT-Hash

The installed crypt(5) page sorts them like this:

• Recommended for new hashes: yescrypt, gost-yescrypt and scrypt.
• Acceptable, with a catch: sha512crypt and sha256crypt. Their default cost of 5000 is too low for modern hardware.
• Compatibility only: bcrypt, which has a 72-byte passphrase limit.

Do not choose md5crypt, sha1crypt, SunMD5, bsdicrypt, descrypt, bigcrypt or NT for a new password store. The older formats exist for compatibility.

Traditional DES truncates the passphrase to eight characters and has a small salt space, so every password hashed with it is guessable on modern hardware. Needing to talk to an old consumer is a reason to use a weak format, not evidence that it is safe.

5. Keep the result out of configuration mistakes

A hash is still sensitive authentication data. Anyone who obtains it can make offline guesses.

• Store the whole result. Put it in the password field your authentication stack expects.
• Protect the file. Follow the permissions documented in shadow(5).
• Keep it out of logs. Never log the plaintext passphrase or the generated result unnecessarily.

In software, use crypt(3) with the stored hash as its setting, or a higher-level password library that deliberately supports the target format. For new application databases, check whether a modern password-hashing library with an explicit cost policy suits you better than the compatibility-oriented crypt(5) family.

6. Verify your interpretation

Re-read the local contracts when a deployment depends on a particular prefix or cost. These commands change nothing:

$ man 5 crypt
$ man 3 crypt
$ man 3 crypt_gensalt

Then run two simple checks:

• Fresh salt, fresh output. The output for the same passphrase should change each time a random salt is generated.
• Prefix matches method. Expect $y$ for yescrypt or $6$ for sha512crypt.

If either check fails, keep the exact output and investigate the installed implementation before using it for an account.