What is purpose of /etc/shadow and shadow cache files in Linux operating system?
From the beginning, Unix and Unix-style operating systems (including Linux) have always stored passwords as cryptographic hashes (1). These hashes were originally stored in /etc/passwd
, but this file needed to be world-readable to make the information available for other purposes - even a simple ls -l
needs to read /etc/passwd
in order to convert each file owner's numeric user id to their username for display. However, having the hashed passwords in a world-readable file allowed malicious users to easily obtain those hashes and attempt to generate usable passwords(2) for other users' accounts.
To prevent this, the hashed passwords were eventually moved into a file readable only by root (and occasionally a privileged group of administrators), /etc/shadow
. This hides the hashes from normal users of the system while keeping them available for user authentication purposes.
Notes:
Pedantic, I know, but the stored passwords are not encrypted. They are hashed using a cryptographically-secure (at least as of the time it was written) hashing algorithm. The primary distinctions relevant here are that hashes are fixed-length (the length of encrypted text varies based on the length of the text which was encrypted) and non-reversible (encrypted text can be decrypted; hashed text cannot).
Because hashes are fixed-length, there are an infinite number of inputs which will match any given hashed representation. An attacker could, therefore, find a working password which is not necessarily the same as the owning user's password - although this is very unlikely given the size of modern crypto hashes.
The /etc/shadow
file was created for security reasons, and holds each user's encrypted password.
Originally, the encrypted password was stored in /etc/passwd
. /etc/passwd
had to be world readable so that the system could map userids to user names, and so that users could find out information about each other, e.g. the other user's home directory, or their phone number, which was traditionally stored in the "gecos" field and displayed by the "finger" utility.
But then people realized that this was a security problem. Anybody with enough time could do what's called a bruteforce attack, by programatically generating encrypted passwords for every possible password. If the attacker did that without actually trying to log in via telnet
or ssh
, the system could not know that it was being attacked.
So the encrypted password was moved into the newly created /etc/shadow
, which is readable only by root.
It also contains other information that the /etc/passwd
file did not support related to the user's account and password, e.g. when the password was last changed and when it will expire.
See man 5 shadow
(web version) for full details of the file format.
I can't say whether it is the same for SUSE, without knowing which version of SUSE you are dealing with. For example, your SUSE system may use Blowfish rather than MD5.
You also implied you were mixing your /etc/shadow
file with a system running a different Linux distribution, but did not say what the other distribution was.
See Problems migrating shadow file from SuSE 9.3 to Ubuntu Server x86_64 for example.
To try to figure it out, open up /etc/shadow
and see whether the encrypted password field starts with $1$
or $2$
. If it contains $1$
, then it's MD5, and compatible with most other distributions. If it contains $2$
, then it's probably Blowfish according to Blowfish shadow files on Debian.
If you are using Ubuntu, the first Google search result for Ubuntu blowfish might be a good starting place.
Users are listed in the /etc/passwd
file. This file contains many information used by the systemm not only to allow users to log in.
Each line corresponds to a user entry and different fields are separated by colons. The first filed is the login, it is followed by the corresponding password.
Encrypted passwords used to be stored in this field. However, the /etc/passwd
file has to be readable by everyone on the system, so encryption does not prevent from brute force attacks, as it has been said by @Mikel. The solution was to move these encrypted passwords in root-only readable file: /etc/shadow
.
Thus, /etc/shadow
contains the encrypted passwords of the system's users. The system knows it has to check for passwords in this file when password fields in /etc/passwd
contain an x alone (meaning "cross over to /etc/shadow")