Because the passwd file is world-readable, encrypted passwords have been moved to a separate file /etc/shadow. Its first field is the account name (just like the passwd file) and the file is colon-delmited. /etc/shadow is readable only by root (actually its permissions are 0). It is also in a special SELinux context. The addition of this separate file of encrypted passwords also allowed the addition of new account parameters to control account and password aging. These are the remaining fields in the shadow file. (We will give an example of the shadow format shortly.)

The shadow file is read-protected because if you can see an encrypted password you can eventually crack it. As previously discussed, encrypted passwords should never be displayed or made available. If the encrypted password is obtained, the length of time you have until it is cracked depends on the type of encryption used (this can range from minutes to years.)

The encrypted password is stored in field two of the shadow file. Unless the encrypted password is an old DES password (which it should not be (see below)), its format is

$N$salt$encryptedpassword

The N is a single digit which indicates the type of encryption used where

• N=1 indicates MD5. This is easy to crack (not secure) and is very short.

• N=5 indicates an SHA-256 password. This is much better (fewer passwords will produce the targeted encrypted password), and harder to crack.
• N=6 indicates an SHA-512 password. Double the length of SHA-256, these passwords are very time-consuming to crack.
  

Again, avoid publishing the encrypted passwords. One common pitfall here is the injudicious use of an NIS database where the passwd and the shadow file are 'merged'. In this configuration, the shadow passwords are "pushed" to the clients with the passwd file and can easily be displayed by an unprivileged user. Even if the files are not merged, NIS will transmit the encrypted password across the network when authentication is requested.

Illegal encrypted passwords

Certain characters in encrypted passwords are illegal. Notable ones are the asterisk (*) and the exclamation mark (!). If an encrypted password contains these characters, the account cannot be logged into using a password. (It can still be logged into using an ssh key.) The passwd -l user command can be used to lock a user's password. (Again, this does not disable the account. You must set the user's shell to /sbin/nologin to disable the account.)

Password Aging

The remaining fields in the shadow file control the use of the account password. This includes when the password {may, must be} changed, when it expires, etc. (Note that these parameters only govern the access of the account using the password. Access using ssh keys is still allowed!) The complete syntax of the shadow file is

login:passwd:lastchange date:minage:maxage:warning:inactivity:expiration date:reserved

All fields are expressed in days. For date fields (lastchange and expiration), this is the number of days since the beginning of Unix time (Jan 1, 1970). For relative fields, this is a number of days (used in arithmetic with the lastchange date). (Converting dates to a day number and the reverse is an interesting side topic. We will discuss this in a subsection following.)

• lastchange date - the date (number of days since 01/01/1970) that the password was last changed. A value of 0 means the password must be changed at the next login.
  
• minage - the password cannot be changed until the date is lastchange+minage. (Empty or 0 means the password can be changed at any time.)
  
• maxage - the password must be changed when the date is lastchange+maxage. (This is the password expiration date.) (Empty means passwords never expire - hence the maxage, warning, and inactivity fields are unused.)
  
• warning - the user will be warned that a password change is required when the date is lastchange+maxage-warning (or within warning days of the password expiration) (Empty or 0 means no warning period)
  
• inactivity - the user will still be allowed to change their password until inactivity days after the password expiration. (Empty means no inactivity period). After that, the password will no longer work. (ssh-key login should still be allowed)
  
• expiration date - the account expiration date. After this date, logins will no longer be allowed. Empty means the account never expires. 0 should not be used.
  

If the current day number is 15877 (June 20, 2013), let's look at the meaning of the following shadow line:

foobar:encryptedpass:15840:14:45:10:30:16071:

• on 05/15/2013, the password was last changed
• it expires 45 days later, about the end of June. foobar can change the password after 05/29/2013.
  
• 10 days before the password expiration, foobar is warned at login that the password must be changed.
• If foobar does not change the password within 30 days of its expiry (about the end of July), the password will be unusable.
  
• The account will expire about 231 days after the last password change, or 231 days after May 15, 2013. After this time, logins using the password will no longer work.

Let's analyze these by examining the day numbers directly, and assign dates to each event. Before we do that, we must review a feature of the date command, some shell arithmetic, and learn a new date feature:

You may recall that date will output the date in a flexible format by using a format string. One interesting format string is +%s, which outputs the date in Unix time, which is seconds since Jan 1, 1970 UTC (seconds since the Epoch):

$ date +%s
1371840372
$

This output indicates the Unix time of now. Sometimes we'd like to interpret a different date. For example, if you were given the date expressed as that above, what is the date in human-readable format?

A different date (other than now) can be used as the input to the date command by specifying it in the argument --date=STRING, where STRING is the date string you are interested in. In our case, the date string is Unix time, and, for date to understand this, it must be preceded by @. Thus, we can interpret this date like this:

$ date --date=@1371840372
Fri Jun 21 11:46:12 PDT 2013
$

If you are given a date as a day number, all you need to do to interpret it is to convert it to Unix time and run it through date, as shown above. Let's do that with the 'last password change' date in our shadow entry:

$ utime=$((15840*60*60*24))
$ echo $utime
1368576000
$ date --date=@1368576000
Tue May 14 17:00:00 PDT 2013
$

There is a little bit of a problem here. Remember we said that dates expressed as Unix time are UTC (Coordinated Universal Time, previously called Greenwich Mean Time). When it was interpreted it was adjusted to Pacific Daylight Time. We want the real date in UTC. We can do that by setting the TZ (timezone) environment variable for the date command:

$ TZ=UTC date --date=@1368576000
Wed May 15 00:00:00 UTC 2013

Fortunately, you don't have to convert dates directly as we discussed above. You can use the chage command to set and interpret shadow dates. The first step is to output a shadow entry with the dates interpreted for you. In the case of our shadow entry:

foobar:encryptedpass:15840:14:45:10:30:16071:

we can use the list feature (chage -l)

# chage -l foobar
Last password change                                : May 15, 2013
Password expires                                    : Jun 29, 2013
Password inactive                                   : Jul 29, 2013
Account expires                                     : Jan 01, 2014
Minimum number of days between password change      : 14
Maximum number of days between password change      : 45
Number of days of warning before password expires   : 10

chage options are pretty simple. There are options to set the last password change date (-d), the password expiration date (the last password change date plus the maximum days between changes), the inactive date (I), the account expiration date (-E), the min (-m) and max (-M) days and the warning days (-W). Each of these takes either a day number (for last change and account expiration dates) or number of days OR a date in the format YYYY/MM/DD. For example,

# chage -M 30 foobar

results in

# chage -l foobar
Last password change                                : May 15, 2013
Password expires                                    : Jun 14, 2013
Password inactive                                   : Jul 14, 2013
Account expires                                     : Jan 01, 2014
Minimum number of days between password change      : 14
Maximum number of days between password change      : 30
Number of days of warning before password expires   : 10

A common use of chage is to set an initial (insecure) password and force the user to change it at first login. Setting the last password change date to time 0 is effective and simple for this:

chage -d 0  login

You can also use a special option to passwd:  passwd -e login