6.3.2.2. /etc/shadow


Because the /etc/passwd file must be world-readable (the main reason being that this file is used to perform the translation from UID to username), there is a risk involved in storing everyone's password in /etc/passwd. True, the passwords are encrypted. However, it is possible to perform attacks against passwords if the encrypted password is available.
If a copy of /etc/passwd can be obtained by an attacker, an attack that can be carried out in secret becomes possible. Instead of risking detection by having to attempt an actual login with every potential password generated by password-cracker, an attacker can use a password cracker in the following manner:
  • A password-cracker generates potential passwords
  • Each potential password is then encrypted using the same algorithm as the system
  • The encrypted potential password is then compared against the encrypted passwords in /etc/passwd
The most dangerous aspect of this attack is that it can take place on a system far-removed from your organization. Because of this, the attacker can use the highest-performance hardware available, making it possible to go through massive numbers of passwords very quickly.
Therefore, the /etc/shadow file is readable only by the root user and contains password (and optional password aging information) for each user. As in the /etc/passwd file, each user's information is on a separate line. Each of these lines is a colon delimited list including the following information:
  • Username — The name the user types when logging into the system. This allows the login application to retrieve the user's password (and related information).
  • Encrypted password — The 13 to 24 character password. The password is encrypted using either the crypt(3) library function or the md5 hash algorithm. In this field, values other than a validly-formatted encrypted or hashed password are used to control user logins and to show the password status. For example, if the value is ! or *, the account is locked and the user is not allowed to log in. If the value is !! a password has never been set before (and the user, not having set a password, will not be able to log in).
  • Date password last changed — The number of days since January 1, 1970 (also called the epoch) that the password was last changed. This information is used in conjunction with the password aging fields that follow.
  • Number of days before password can be changed — The minimum number of days that must pass before the password can be changed.
  • Number of days before a password change is required — The number of days that must pass before the password must be changed.
  • Number of days warning before password change — The number of days before password expiration during which the user is warned of the impending expiration.
  • Number of days before the account is disabled — The number of days after a password expires before the account will be disabled.
  • Date since the account has been disabled — The date (stored as the number of days since the epoch) since the user account has been disabled.
  • A reserved field — A field that is ignored in Red Hat Enterprise Linux.
Here is an example line from /etc/shadow:
 juan:$1$.QKDPc5E$SWlkjRWexrXYgc98F.:12825:0:90:5:30:13096: 
This line shows the following information for user juan:
  • The password was last changed February 11, 2005
  • There is no minimum amount of time required before the password can be changed
  • The password must be changed every 90 days
  • The user will get a warning five days before the password must be changed
  • The account will be disabled 30 days after the password expires if no login attempt is made
  • The account will expire on November 9,2005
For more information on the /etc/shadow file, see the shadow(5) man page.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.