What is purpose of /etc/shadow and shadow cache files in Linux operating system?
Solution 1:
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.
Solution 2:
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.
Solution 3:
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")
Solution 4:
Let's see if I can get all the up-votes in the world, since I wrote what became the Linux Shadow Password Suite in '87 ;)
The original /etc/passwd file contained a modified DES-based hash of the cleartext password. At the time the crypt() function was created, it was believed (and this was stated by the creators of the UNIX operating system) that attacks against the password hash would be infeasible, due to the number of possible passwords and the use of a 12-bit (4,096 possible values) "salt". Each possible cleartext password had 4,096 possible hashed values, and with 64-bits of hashed result, that gave a total of 2^72 possible password hashes.
As another poster mentioned, /etc/passwd was also used by various utilities to map between user names and UID values (the /etc/group file provides the analogous function for groups) and that required it be world-readable.
In the 1980s it became obvious that dictionary attacks against the password hash stored in the /etc/passwd file were becoming feasible and /etc/shadow was introduced to AT&T UNIX in an early release of System V. I documented which manpages I used to write the original Shadow library, and I've since forgotten, but it was definitely an early System V release, probably SVR3.2.
What AT&T did, and what I implemented for SCO Xenix (the original SCO Xenix, not the later evil SCO Xenix) in '87 that eventually came into use on Linux, was simply move the hashed password to /etc/shadow. This prevented the drive-by attack, where an unprivileged user acquired a copy of /etc/passwd and ran an attack against it. If you're familiar with why I wrote Shadow in the first place, I had a user download my /etc/passwd file via UUCP back in the days when we still used UUCP for just about everything.
By the time Linux was created and came into wide-spread use, there were a very large number of tools for attacking password hashes. High-performance re-implementations of crypt() were one avenue, and dictionary-based attacks via tools such as Crack and libcrack were others. The initial port was done by Nate Holloway and Floria La Roche (I gave them credit, I don't know if anyone did the work before them).
Eventually the use of crypt()-based hashes, even in a protected file, was no longer secure and the original MD5-based hash changes were made. MD5 eventually was considered to be too weak, and newer hashes were used.
In theory, a strong enough hash could be stored in /etc/passwd. Poor operational security means that many systems have their /etc/shadow files available through various attack vectors -- "I stole the backup files" is probably the easiest.