Crypt (C)
crypt is the library function which is used to compute a password hash that can be used to store user account passwords while keeping them relatively secure (a <TT></TT> file). The output of the function is not simply the hash it is a text string which also the (usually the first two characters are the salt itself and the rest is the hashed result), and identifies the hash algorithm used (defaulting to the “traditional” one explained below). This output string is what is meant for putting in a password record which may be stored in a plain text file.
More formally, crypt provides cryptographic key derivation functions for password validation and storage on Unix systems.
Contents
Relationship to Unix crypt utility
There is a crypt utility in Unix, which is often confused with the C library function. To distinguish between the two, writers often refer to the utility program as crypt(1), because it is documented in section 1 of the Unix , and refer to the C library function as crypt(3), because its documentation is in manual section 3.
Details
This same crypt function is used both to generate a new hash for storage and also to hash a proffered password with a recorded for comparison.<!– TODO: example in pseudocode or Perl –>
Modern Unix implementations of the crypt library routine support a variety of hash schemes. The particular hash algorithm used can be identified by a unique code prefix in the resulting hashtext, following a de facto standard called Modular Crypt Format.
The <code>crypt()</code> library function is also included in the , , , Python, and programming languages.
Key derivation functions supported by crypt
Over time various algorithms have been introduced. To enable , each scheme started using some convention of the that was later called the Modular Crypt Format (MCF).:
<code>$<id>[$<param>=<value>(,<param>=<value>)*][$<salt>[$<hash>]]</code>
where
- <code>id</code>: an identifier representing the hashing algorithm (such as 1 for MD5, 5 for SHA-256 etc.)
- <code>param</code> name and its <code>value</code>: hash complexity parameters, like rounds/iterations count
- <code>salt</code>: -like encoded
- <code>hash</code>: -like encoded result of hashing the password and salt
| Scheme id | Schema | Example |
|---|---|---|
| <code>Kyq4bCxAXJkbg</code> | ||
| _ | <code>_EQ0.jzhSVeUyoSqLupI</code> | |
| 1 | MD5 | <code>$1$etNnh7FA$OlM7eljE/B7F1J4XYNnk81</code> |
| 2, 2a, 2x, 2y | bcrypt | <code>$2a$10$VIhIOofSMqgdGlL4wzE//e.77dAQGqntF/1dT7bqCrVtquInWy2qi</code> |
| 3 | <code>$3$$8846f7eaee8fb117ad06bdd830b7586c</code> | |
| 5 | SHA-256 | <code>$5$9ks3nNEqv31FX.F$gdEoLFsCRsn/WRN3wxUnzfeZLoooVlzeF4WjLomTRFD</code> |
| 6 | SHA-512 | <code>$6$qoE2letU$wWPRl.PVczjzeMVgjiA8LLy2nOyZbf7Amj3qLIL978o18gbMySdKZ7uepq9tmMQXxyTIrS12Pln.2Q/6Xscao0</code> |
| md5 | Solaris MD5 | <code>$md5,rounds=5000$GUBv0xjJ$$mSwgIswdjlTY0YxV7HBVm0</code> |
| sha1 | PBKDF1 with SHA-1 | <code>$sha1$40000$jtNX3nZ2$hBNaIXkt4wBI2o5rsi8KejSjNqIq</code> |
Original implementation using the password as a key
The original implementation of the crypt() library function in Third Edition Unix mimicked the cipher machine. Rather than encrypting the password with a key, which would have allowed the password to be recovered from the encrypted value and the key, it used the password itself as a key, and the password database contained the result of encrypting the password with this key.
Traditional DES-based scheme
The original password encryption scheme was found to be too fast and thus subject to brute force enumeration of the most likely passwords. the scheme was changed to a modified form of the algorithm. A goal of this change was to make encryption slower. In addition, the algorithm incorporated a 12-bit in order to ensure that an attacker would be forced to crack each password independently as opposed to being able to target the entire password database simultaneously.
In detail, the user’s password is truncated to eight characters, and those are coerced down to only 7-bits each; this forms the 56-bit DES key. That key is then used to encrypt an all-bits-zero block, and then the ciphertext is encrypted again with the same key, and so on for a total of 25 DES encryptions. A 12-bit salt is used to perturb the encryption algorithm, so standard DES implementations can’t be used to implement crypt(). The salt and the final ciphertext are encoded into a printable string in a form of .
This is technically not encryption since the data (all bits zero) is not being kept secret; it’s widely known to all in advance. However, one of the properties of DES is that it’s very resistant to key recovery even in the face of situations. It is theoretically possible that two different passwords could result in exactly the same hash. Thus the password is never “decrypted”: it is merely used to compute a result, and the matching results are presumed to be proof that the passwords were “the same.”
The advantages of this method have been that the hashtext can be stored and copied among Unix systems without exposing the corresponding plaintext password to the system administrators or other users. This portability has worked for over 30 years across many generations of computing architecture, and across many versions of Unix from many vendors.
Weaknesses of the traditional scheme
The traditional DES-based crypt algorithm was originally chosen because DES was resistant to key recovery even in the face of “known plaintext” attacks, and because it was computationally expensive. On the earliest Unix machines it took over a full second to compute a password hash. This also made it reasonably resistant to in that era. At that time password hashes were commonly stored in an account file (<code>/etc/passwd</code>) which was readable to anyone on the system. (This account file was also used to map user ID numbers into names, and user names into full names, etc.).
In the three decades since that time, computers have become vastly more powerful. has generally held true, so the computer speed and capacity available for a given financial investment has doubled over 20 times since Unix was first written. This has long since left the DES-based algorithm vulnerable to dictionary attacks, and Unix and Unix-like systems such as Linux have used for a long time, migrating just the password hash values out of the account file (<code>/etc/passwd</code>) and into a file (conventionally named <code>/etc/shadow</code>) which can only be read by privileged processes.
To increase the computational cost of password breaking, some Unix sites privately started increasing the number of encryption rounds on an ad hoc basis. This had the side effect of making their <code>crypt()</code> incompatible with the standard <code>crypt()</code>: the hashes had the same textual form, but were now calculated using a different algorithm. Some sites also took advantage of this incompatibility effect, by modifying the initial block from the standard all-bits-zero. This did not increase the cost of hashing, but meant that precomputed hash dictionaries based on the standard crypt() could not be applied.
BSDi extended DES-based scheme
used a slight modification of the classic DES-based scheme. BSDi extended the salt to 24 bits and made the number of rounds variable (up to 2<sup>24</sup>-1). The chosen number of rounds is encoded in the stored password hash, avoiding the incompatibility that occurred when sites modified the number of rounds used by the original scheme. These hashes are identified by starting with an underscore (<code>_</code>), which is followed by 4 bytes representing the number of rounds.
The BSDi algorithm also supports longer passwords, using DES to fold the initial long password down to the eight 7-bit bytes supported by the original algorithm.
MD5-based scheme
designed a baroque and (at the time) computationally expensive algorithm based on the MD5 message digest algorithm. MD5 itself would provide good cryptographic strength for the password hash, but it is designed to be quite quick to calculate relative to the strength it provides. The crypt() scheme is designed to be expensive to calculate, to slow down dictionary attacks. The printable form of MD5 password hashes starts with <code>$1$</code>.
This scheme allows users to have any length password, and they can use any characters supported by their platform (not just 7-bit ASCII). (In practice many implementations limit the password length, but they generally support passwords far longer than any person would be willing to type.) The salt is also an arbitrary string, limited only by character set considerations.
First the passphrase and salt are hashed together, yielding an MD5 message digest. Then a new digest is constructed, hashing together the passphrase, the salt, and the first digest, all in a rather complex form. Then this digest is passed through a thousand iterations of a function which rehashes it together with the passphrase and salt in a manner that varies between rounds. The output of the last of these rounds is the resulting passphrase hash.
The fixed iteration count has caused this scheme to lose the computational expense that it once enjoyed and variable numbers of rounds are now favoured. In June 2012, Poul-Henning Kamp declared the algorithm insecure and encouraged users to migrate to stronger password scramblers.
Blowfish-based scheme
Niels Provos and designed a crypt() scheme called bcrypt based on , and presented it at in 1999. The printable form of these hashes starts with <code>$2$</code>, <code>$2a$</code>, <code>$2b$</code>, <code>$2x$</code> or <code>$2y$</code> depending on which variant of the algorithm is used:
- <code>$2$</code> Currently obsolete
- <code>$2a$</code> The current key used to identify this scheme. Since a major security flaw was discovered in 2011 in a third-party implementation of the algorithm, hashes indicated by this string are now ambiguous and might have been generated by the flawed implementation, or a subsequent fixed, implementation. The flaw may be triggered by some password strings containing non-ASCII characters, such as specially crafted password strings.
- <code>$2b$</code> Used by some recent implementations which include a mitigation to a wraparound problem. Previous versions of the algorithm have a problem with long passwords. By design, long passwords are truncated at 72 characters, but there is an 8-bit wraparound problem with certain password lengths resulting in weak hashes.
- <code>$2x$</code> Post-2011 bug discovery, old hashes can be renamed to be <code>$2x$</code> to indicate that they were generated with the broken algorithm. These hashes are still weak, but at least it’s clear which algorithm was used to generate them.
- <code>$2y$</code> Post Post-2011 bug discovery, <code>$2y$</code> may be used to unambiguously use the new, corrected algorithm. On an implementation suffering from the bug, <code>$2y$</code> simply won’t work. On a newer, fixed implementation, it will produce the same result as using <code>$2a$</code>.
Blowfish is notable among block ciphers for its expensive key setup phase. It starts off with subkeys in a standard state, then uses this state to perform a block encryption using part of the key, and uses the result of that encryption (really, a hashing) to replace some of the subkeys. Then it uses this modified state to encrypt another part of the key, and uses the result to replace more of the subkeys. It proceeds in this fashion, using a progressively modified state to hash the key and replace bits of state, until all subkeys have been set.
The number of rounds of keying is a power of two, which is an input to the algorithm. The number is encoded in the textual hash, e.g. <code>$2y$10…</code>
NT hash scheme
FreeBSD implemented support for the hash algorithm to provide easier compatibility with NT accounts. The NT-Hash algorithm is known to be weak, as it uses the deprecated md4 hash algorithm without any salting. FreeBSD used the <code>$3$</code> prefix for this. Its use is not recommended, as it is easily broken.
SHA2-based scheme
The commonly used MD5 based scheme has become easier to attack as computer power has increased. Although the Blowfish-based system has the option of adding rounds and thus remain a challenging password algorithm, it does not use a -approved algorithm. In light of these facts, of led an effort to create a scheme based on the SHA-2 (SHA-256 and SHA-512) hash functions. The printable form of these hashes starts with <code>$5$</code> (for SHA-256) or <code>$6$</code> (for SHA-512) depending on which SHA variant is used. Its design is similar to the MD5-based crypt, with a few notable differences:
The specification and sample code have been released into the public domain.
Support in operating systems
| Scheme id | Scheme | Linux () | FreeBSD | NetBSD | OpenBSD | Solaris | MacOS |
|---|---|---|---|---|---|---|---|
| DES | y | y | y | y | y | y | |
| _ | BSDi | y | y | y | y | ||
| 1 | MD5 | y | y | y | y | y | |
| 2, 2a, 2x, 2y | bcrypt | y | y | y | y | ||
| 3 | NTHASH | y | |||||
| 5 | SHA-256 | 2.7+ | 8.3+ | y | |||
| 6 | SHA-512 | 2.7+ | 8.3+ | y | |||
| md5 | Solaris MD5 | y | |||||
| sha1 | PBKDF1 with SHA1 | y |
Archaic Unix schemes
BigCrypt is the modified version of DES-Crypt used on HP-UX, Digital Unix, and OSF/1. The main difference between it and DES is that BigCrypt uses all the characters of a password, not just the first 8, and has a variable length hash.
Crypt16 is the minor modification of DES, which allows passwords of up to 16 characters. Used on Ultrix and Tru64.
GNU/Linux
The used by almost all GNU/Linux distributions provides an implementation of the crypt function which supports the DES, MD5, and (since version 2.7) SHA-2 based hashing algorithms mentioned above. Ulrich Drepper, the glibc maintainer, rejected bcrypt support since it isn’t approved by .
macOS
Darwin’s native <code>crypt()</code> provides limited functionality, supporting only DES and BSDi. OS X uses a separate system for its own password hashes.
Twitter
Telegram
