On a Linux system without the Shadow Suite installed, user information including passwords is stored in the /etc/passwd file. The password is stored in an encrypted format. If you ask a cryptography expert, however, he or she will tell you that the password is actually in an encoded rather than encrypted format because when using crypt(3), the text is set to null and the password is the key. Therefore, from here on, I will use the term encoded in this document.
The algorithm used to encode the password field is technically referred to as a one way hash function. This is an algorithm that is easy to compute in one direction, but very difficult to calculate in the reverse direction. More about the actual algorithm used can be found in section 2.4 or your crypt(3) manual page.
When a user picks or is assigned a password, it is encoded with a randomly generated value called the salt. This means that any particular password could be stored in 4096 different ways. The salt value is then stored with the encoded password.
When a user logs in and supplies a password, the salt is first retrieved from the stored encoded password. Then the supplied password is encoded with the salt value, and then compared with the encoded password. If there is a match, then the user is authenticated.
....
The Shadow Suite solves the problem by relocating the passwords to another file (usually /etc/shadow). The /etc/shadow file is set so that it cannot be read by just anyone. Only root will be able to read and write to the /etc/shadow file. Some programs (like xlock) don't need to be able to change passwords, they only need to be able to verify them. These programs can either be run suid root or you can set up a group shadow that is allowed read only access to the /etc/shadow file. Then the program can be run sgid shadow.