Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
Recent versions of Unix store encrypted passwords in a file that is not publicly accessible. Such files are called shadow password files.
In the UNIX password scheme, if only the operating system and system administrators have access to the password file. What are the security requirements for the underlying encryption function Ek?
Most people would not call what we do to store passwords encryption as it is not reversible. It's a cryptographic hash.
Also the diagram has some specific numbers which correspond to the orignal unix DES based system which nobody should be using any more for many reasons but mainly only 8 chars ASCII passwords. The principals however remain the same.
We want to protext the system also in the event of data from the shadow file is leaked ans to a limited extent from the system adminstrator. It should be impossible to recover the plain text password from what we store, anyone trying to brute force the passwords should need to this one password at a time and not all together. Brute forcing passwords should be a slow process. It should not be practical to precompute rainbow tables for even a faily modest collection of passwords. We should still be able to verify a given plain text matches the stored record and it should be extremely unlikely another password will accidentally match.
We do this with a special kind of cryptographic hash function and with the help a random salt. The salt (originally 12 bits nowadays more) makes attaxking passwords together and building rainbow tables very difficult. And the hash function should be slow so a single password brute force is impractical.
Since the original implementation we also add that speed should be paramaterized so we can increase compute difficulty as computers become faster. This was missing in the original unix implementation.
Also we want to support long passwords and we want the hash function to preserve as much of the entropy in the password as possible (unlike the infamous LanMan). The hash function should be preimage and collision resistant (unlike the LanMan). Some may want to add diverse charset support which many now use to increase password entropy.
Passwords are in fact not encrypted, but hashed. The properties required to store passwords are completely different from the properties of encryption. In particular, encryption can be reversed by decryption, whereas it is not desirable to be able to recover a password from its stored form.
The terminology “crypt” survives because early ways to hash passwords were based on an encryption primitive and because the required properties of a password hash were not fully understood at the time. I recommend reading Robert Morris and Ken Thompson's 1978 article “Password Security: A Case History” for historical interest; they had already identified the important properties of a password hash, but the term “hash” wasn't established yet.
The password file contains a password hash of the password. A password hash is a special kind of cryptographic hash which is specially tuned to be costly to reverse: it must be slow (which hits the legitimate server and the attacker equally per attempt, but the attacker has to make many attempts), and diversified with a salt (which forces the attacker to crack each account independently). See Thomas Pornin's reference answer for an excellent explanation.
