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. In RH6.5, this is simple - just use grub-crypt with one of the options --md5, --sha256 or --sha512. In both systems you can use a single line python script as below:

python -c 'import crypt; print(crypt.crypt("mypassword", "$6$MySalt"))'

where mypassword is the password you want to encrypt and MySalt is some random characters to use as the password "salt". (The "salt" used in sha-512 is 16 random characters.)

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.) We discuss the format of the shadow file and the encrypted passwords themselves in the next section.

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

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.)

Account breakins

There are generally two methods for breaking passwords. Each relies on trying successive guesses, but how these guesses are generated varies

• Directly guessing the password. There are several possible mechanisms here:
• initial passwords, such as those given by many organizations when the account is created. If you ever have an account created for you and the password algorithm is published so that it is fairly easily guessed, you should immediately login and change the password.
• passwords that are stupidly given to you in an email message. Dont worry, there are programs on the Internet sifting through traffic for such words as 'password' and squirreling away their context for examination. If you ever must communicate a password via email, use some form of a shared secret, such as 'the last four digits of  your employee id followed by ...', or, better, use a telephone. And dont include the word password or login in the email. Another example of this is using an insecure protocol to login to an account. Examples of insecure protocols, during which the password is transmitted in clear text, are ftp and telnet. Never use these (other than anonymous ftp).
  
• passwords that can be directly guessed. Because most Linux systems today have password strength checkers that will refuse to create passwords that are derived from dictionary words, the most-easily guessed passwords are disallowed. Unfortunately, however, it is easy to fool these password checkers. A common practice is to use a password that is a simple word in another language. If the password checker does not have access to that language's dictionary, the password may be allowed. If the account holder's name is known and his or her ethnicity may be determined and matched to the password's language, guessing the password turns out to be very easy! (There is actually a very important local example of this here at CCSF.)

direct guessing of passwords have the disadvantage that it can be very slow and can be discouraged by program timeouts and limiting the number of password tries per connection. If system access is limited to a protocol such as ssh, only very poorly-designed passwords are susceptible to this mechanism.

• 'cracking' the password off-line. This technique relies on obtaining a copy of the encrypted passwords and running a fast algorithm to attempt to regenerate the encrypted password. Since passwords are 'hashed', it is possible for many passwords to generate the same encrypted password. (This means that multiple passwords are identical and can be used interchangeably. ) The number of interchangeable passwords is inversely proportional to the complexity (length) of the resulting hash. If a long hash (such as SHA-512) is used, the ease at which it can be duplicated may be determined by the randomness and length of the password itself.
  The bottom line here is that the encrypted passwords must also be protected. If an encrypted password is known, it can eventually be broken.
  

Generating and 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 the password does not work. 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. Locking the password does not disable the account. It can still be accessed using an ssh key.
  
• 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!