Due to the ability of fast computers to "crack" encrypted passwords given sufficient time, passwords today are typically stored in a file that is not world-readable, called the shadow file. Besides stronger encryption and restricted access, the shadow package used on linux provides password and account aging and expiration parameters. These allow the specification of 

• an account expiration date
• how often the password must be changed
• what to do if a password expires and the user does not change it. 

These parameters default to "the password never has to be changed and the account never expires". The parameters for a particular password can be altered using the program chage(1). See shadow(5) for the syntax of the shadow file.

The encrypted password stored in the shadow file can be generated using two algorithms: MD5 and SHA. In addition, SHA has two variations - 256 and the longer 512. Currently, passwords on linux use SHA-512 encrypted passwords. You can actually generate an encrypted password at the command-line if you like using grub-crypt with one of the options --md5, --sha256 or --sha512. If you simply cut and paste the [correctly encrypted] password into /etc/shadow you would change the password. Alternately, the encrypted password can be used as an option to useradd when creating an account. (Since encrypted passwords are 'salted', two encrypted passwords generated from the same actual password will be the same only if the salt is the same.)

The password encryption algorithm currently used on the system may be found in /etc/sysconfig/authconfig in the variable PASSWDALGORITHM. You must use the encryption algorithm indicated there for the password generated by grub-crypt. Otherwise the password will not work.

When an account is created without setting a password, the passwd file is marked to indicate that the shadow file is being used and the shadow file indicates a !! in the password field to indicate the password has not been set. (Any password in the shadow file that starts with ! is locked. An option of passwd will lock a password, disabling the account, as we will see.)

Handling passwords

With the propagation of "logins" on the Internet today, many users are faced with an ever-increasing number of passwords to remember. Self-preservation forces the adoption of one or more bad habits to deal with this:

• writing down passwords
• reusing the same password
• adoption of a simple password generation scheme using a regular pattern

As the system administrator, you are responsible for the integrity of your system. This means you must not only adopt a reasonable procedure for that most important of all passwords, the root password, but you must encourage good habits in other users. Although the passwd program enforces some basic restrictions such as minimum length and different types of characters and can be configured to use cracklib to test passwords against permutations of dictionary words, this is only a beginning. (Whether your system uses cracklib to check passwords or not and the type of password encryption used are indicated by configuration parameters in /etc/sysconfig/authconfig).

There are several conflicting issues when choosing a password-generation scheme:

• random passwords are hard to remember and prompt users to write them down, which is a security issue.
• most passwords that are memorable (and can get past cracklib) rely on personal information that may be predictable.

One scheme that has been relatively successful is the "memorable phrase" method. Here, a memorable phrase is constructed and a password created from some regular permutation of the characters, replacing some characters with numbers, adding punctuation, and perhaps switching case. For example, given the memorable phrase

passwords are not fun to change!

you could easily derive the password pRnf2c!  Add a little extra complexity such as reversing letters, alternating case, or alternating which letter of the words is selected for inclusion in the final password and you have a reasonable scheme.

The counter to this scheme is that some password cracking programs using a brute-force method will actually cycle through all possible combinations of a certain number of letters. Believers of this argument recommend that password be longer, say a minimum of a dozen letters. This line of thinking advocates longer passwords that are memorable phrases, perhaps with some misspellings. Assuming the only access to your system is via ssh and that hackers cannot access your encrypted passwords, it is doubtful that a brute-force would succeed in a workable amount of time. Most ssh variants only allow a few password attempts per connection, and initiating the connection is time-consuming. Even if no limits were imposed on the number of incorrect password attempts tried and no sys admin noticed the large number of attempts, how many attempts could be made in a day?

Whatever scheme you adopt, you, as the system administrator, must have a recommendation when asked, or when you discover a user password scribbled on the front of a notebook or taped to the front of a computer, as well as needing a reasonable scheme yourself. You're going to feel pretty silly if a user asks you how you remember passwords and you must admit the root password is some permutation of 'secret'. 

One last issue to consider: Forcing users to change their password has become a standard procedure on Unix systems. Unfortunately, it has two major consequences:

• it increases the difficulty of remembering passwords and the temptation to write them down.
• it causes rebellion. Unix users are an especially rebellious bunch. They rebel against anyone forcing them to do anything. They will tend to fight back by recycling passwords or by changing their password and then changing it back, neither of which increases security. I happen to think that a single good password used for a longer period of time is better than cycling through a number of marginal ones, especially if forcing the user to change them results in the list being written in the back of a notebook somewhere.

Creating passwords

One of the responsibilities of the Administrator is fixing passwords as well as locking and disabling accounts. We have all used the passwd program, but there are a few options that are noteworthy for aiding in these duties:

1. passwd will refuse to accept simple passwords for normal users, but not for the administrator. This is helpful when creating a temporary account for testing purposes. Just remember to delete the account when you are done.

2. passwd has three options available only for the administrator:

• passwd -l user locks the account of user so that noone can log in. This sets the password back to the state it is in when the account is first created. passwd -u user unlocks the account, restoring the current password.
  
• passwd -d user deletes the password for user. This opens the account so that anyone can login without a password.
• passwd --stdin user accepts a clear-text password for user from standard input. It would be insane to run this at the command-line (as the password would display on the screen as well as be placed in the history file!), but it is very useful when automating account creation. For example, to set our linux system's initial user passwords, information is retrieved from the student database and used to set the password. Since the information is read from a file that is inaccessible to normal users and the task is automated the passwords are not displayed as they are created even though the data stream is clear text.
• you can also add the password to the account at creation using useradd. The password must be encrypted, but now that you know how to use grub-crypt, that is not a problem!