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

You will finish with a repeatable way to generate a Linux crypt(5) password hash, recognise its method and salt, and understand what can safely be placed in a password database. The examples use libxcrypt 4.4.36-4build1 and the mkpasswd command from whois 5.5.22.

Allow about fifteen minutes. You need a shell and the mkpasswd command. These steps do not edit /etc/shadow, change an account, or require elevated privileges. Use a test passphrase only. A passphrase typed into a command argument can be exposed in 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 name matters because mkpasswd is a front end to the system's crypt(3) implementation. The exact list of methods is a property of that implementation, not a universal promise made by every Unix system.

2. Generate a modern hash with a random salt

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

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

Your result will differ. When no salt is 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

Do not treat different output as a failure. A random salt is supposed to make identical passphrases produce different stored strings. During login, the verifier takes the stored string as the setting, hashes the supplied passphrase with the same method and salt, then compares the result. It does not compare the plaintext with a reversible encrypted copy.

3. Read the four parts of the stored string

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

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

The prefix $y$ selects yescrypt. The j9T field is not a general-purpose setting you should edit by hand. It encodes method-specific cost information. The salt and hash use the alphabet and lengths defined by the method, not necessarily RFC 4648 base64.

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

4. Choose a method without falling into the 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 lists yescrypt, gost-yescrypt and scrypt as recommended for new hashes. It describes sha512crypt and sha256crypt as acceptable, but warns that their default cost of 5000 is too low for modern hardware. bcrypt remains useful where compatibility requires it, with a 72-byte passphrase limit.

Do not choose md5crypt, sha1crypt, SunMD5, bsdicrypt, descrypt, bigcrypt or NT for a new password store. The older formats are present for compatibility. Traditional DES truncates the passphrase to eight characters and has a small salt space, making every password hashed with it guessable on modern hardware. Compatibility with 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 complete result in the password field expected by your authentication stack, protect the file as documented by shadow(5), and never log the plaintext passphrase or the generated result unnecessarily.

For software, use crypt(3) with the stored hash as its setting, or use 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 is more appropriate 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 do not modify anything:

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

Then perform two simple checks. First, the output for the same passphrase should change when a fresh random salt is generated. Second, the prefix should match the method you requested, such as $y$ for yescrypt or $6$ for sha512crypt. If either check fails, preserve the exact output and investigate the installed implementation before using it for an account.

There is no undo operation for these examples because they only calculate hashes in memory and print them. Remove any test output from your shell history or temporary logs if the passphrase was real. If a real credential was exposed, rotate it rather than assuming that deleting the terminal line repaired the exposure.