Every person who uses a Unix computer should have her own account. An account is identified by a user ID number (UID) that is associated with one or more usernames (also known as account names). Traditionally, each account also has a secret password associated with it to prevent unauthorized use. You need to know both your username and your password to log into a Unix system.
The username is an identifier: it tells the computer who you are. In contrast, a password is an authenticator: you use it to prove to the operating system that you are who you claim to be. A single person can have more than one Unix account on the same computer. In this case, each account would have its own username.
Standard Unix usernames may be between one and eight characters long, although many Unix systems today allow usernames that are longer. Within a single Unix computer, usernames must be unique: no two users can have the same one. (If two people did have the same username on a single system, then they would really be sharing the same account.) Traditionally, Unix passwords were also between one and eight characters long, although most Unix systems now allow longer passwords as well. Longer passwords are generally more secure because they are harder to guess. More than one user can theoretically have the same password, although if they do, that usually indicates that both users have picked a bad password.
A username can be any sequence of characters you want (with some exceptions), and does not necessarily correspond to a real person's name.
Your username identifies you to Unix in the same way that your first name identifies you to your friends. When you log into the Unix system, you tell it your username in the same way that you might say, "Hello, this is Sabrina," when you pick up the telephone. Most systems use the same identifier for both usernames and email addresses. For this reason, organizations that have more than one computer often require people to use the same username on every machine to minimize confusion.
 Even if you aren't Sabrina, saying that you are Sabrina identifies you as Sabrina. Of course, if you are not Sabrina, your voice will probably not authenticate you as Sabrina, provided that the person you are speaking with knows what Sabrina actually sounds like.
There is considerable flexibility in choosing a username. For example, John Q. Random might have any of the following usernames; they are all potentially valid:
Alternatively, John might have a username that appears totally unrelated to his real name, like avocado or t42. Having a username similar to your own name is merely a matter of convenience.
Most organizations require that usernames be at least three characters long. Single-character usernames are simply too confusing for most people to deal with, no matter how easy you might think it would be to be user i or x. Usernames that are two characters long are also confusing for some people, because they usually don't provide enough information to match a name in memory: who was email@example.com, anyway? In general, names with little intrinsic meaning, such as t42xp96wl, can also cause confusion because they are more difficult for correspondents to remember.
Some organizations assign usernames using standardized rules, such as the first initial of a person's first name and then the first six letters of their last name, optionally followed by a number. Other organizations let users pick their own names. Some organizations and online services assign an apparently random string of characters as the usernames; although this is generally not popular, it can improve security?especially if these usernames are not used for electronic mail. Although some randomly generated strings can be hard to remember, there are several algorithms that generate easy-to-remember random strings by using a small number of mnemonic rules; typical usernames generated by these systems are xxp44 and acactt. If you design a system that gives users randomly generated usernames, it is a good idea to let people reject a username and ask for another, lest somebody gets stuck with a hard-to-remember username like xp9uu6wi.
Unix also has special accounts that are used for administrative purposes and special system functions. These accounts are not normally used by individual users.
After you tell Unix who you are, you must prove your identity to a certain degree of confidence (trust). This process is called authentication. Classically, there are three different ways that you can authenticate yourself to a computer system, and you use one or more of them each time:
You can tell the computer something that you know (for example, a password).
You can present the computer with something you have (for example, a card key).
You can let the computer measure something about you (for example, your fingerprint).
None of these systems is foolproof. For example, by eavesdropping on your terminal line, somebody can learn your password. By attacking you at gunpoint, somebody can steal your card key. And if your attacker has a knife, you might even lose your finger! In general, the more trustworthy the form of authentication, the more aggressive an attacker must be to compromise it. In the past, the most trustworthy authentication techniques have also been the most difficult to use, although this is slowly changing.
Passwords are the simplest form of authentication: they are a secret that you share with the computer. When you log in, you type your password to prove to the computer that you are who you claim to be. The computer ensures that the password you type matches the account that you have specified. If it matches, you are allowed to proceed.
Unix does not display your password as you type it. This gives you extra protection if the transcript of your session is being logged or if somebody is watching over your shoulder as you type?a technique that is sometimes referred to as shoulder surfing.
Traditionally desktop personal computers running the Windows or Macintosh operating systems, handheld computers, and personal organizers did not require that users authenticate themselves before the computer provided the requested information. The fact that these computers employed no passwords or other authentication techniques made them easier to use.
Likewise, many of the research groups that originally developed the Unix operating system did not have passwords for individual users?often for the same reason that they shied away from locks on desks and office doors. In these environments, trust, respect, and social convention were very powerful deterrents to information theft and destruction. When computer systems required passwords, often times many people shared the same password?password, for example.
Unfortunately, the lack of authentication made these computers easier for many people to use?this included both the machine's primary user and anybody else who happened to be in the area. As these systems were connected to modems or external networks, the poor authentication practices that had grown up in the closed environment became a point of vulnerability, especially when other systems based their trust on the authenticity of the identity determined locally. Vulnerabilities frequently led to successful attacks. There have been many cases in which a single easily compromised account has endangered the security of an entire installation or network.
In today's highly networked world, proper authentication of authorized users is a core requirement of any computer that is trusted with confidential information. The challenge that computer developers now face is to produce systems that provide strong authentication while simultaneously providing ease of use.
Conventional passwords have been part of Unix since its early years. The advantage of this system is that it runs without any special equipment, such as smartcard readers or fingerprint scanners.
The disadvantage of conventional passwords is that they are easily captured and reused?especially in a network-based environment. Although passwords can be used securely and effectively, doing so requires constant vigilance to make sure that an unencrypted password is not inadvertently sent over the network, allowing it to be captured with a password sniffer. Passwords can also be stolen if they are typed on a computer that has been compromised with a keystroke recorder. Today, even unsophisticated attackers can use such tools to capture passwords. Indeed, the only way to safely use a Unix computer remotely over a network such as the Internet is to use one-time passwords, encryption, or both (see Section 4.3.3 later in this chapter and also see Chapter 7).
 Well-chosen passwords are still quite effective for most standalone systems with hardwired terminals, and when used in cryptographic protocols with mechanisms to prevent replay attacks.
Unfortunately, we live in an imperfect world, and most Unix systems continue to depend upon reusable passwords for user authentication. Be careful!
When you log in, you tell the computer who you are by typing your username at the login prompt (the identification step). You then type your password (in response to the password prompt) to authenticate that you are who you claim to be. For example:
login: rachel password: luV2-fred
Unix does not display your password when you type it.
If the password that you supply with your username corresponds to the password that is on file for the provided username, Unix logs you in and gives you full access to the user's files, commands, and devices. If the username and the password do not match, Unix does not log you in.
On some versions of Unix, if somebody tries to log into an account and supplies an invalid password several times in succession, that account will become locked. A locked account can be unlocked only by the system administrator. Locking has three functions:
It protects the system from attackers who persist in trying to guess a password; before they can guess the correct password, the account is shut down.
It lets you know that someone has been trying to break into your account.
It lets your system administrator know that someone has been trying to break into the computer.
If you find yourself locked out of your account, you should contact your system administrator and get your password changed to something new. Don't change your password back to what it was before you were locked out.
The automatic lockout feature can prevent unauthorized use, but it can also be used to conduct denial of service attacks, or by an attacker to lock selected users out of the system so as to prevent discovery of his actions. A practical joker can use it to annoy fellow employees or students. And you can accidentally lock yourself out if you try to log in too many times before you've had your morning coffee.
In our experience, the disadvantages of indefinite automatic lockouts outweigh the benefits. A much better method is to employ an increasing delay mechanism in the login. After a fixed number of unsuccessful logins, an increasing delay can be inserted between each successive prompt. Implementing such delays in a network environment requires maintaining a record of failed login attempts, so that the delay cannot be circumvented by an attacker who merely disconnects from the target machine and reconnects.
You can change your password with the Unix passwd command. You will first be asked to type your old password, then a new one. By asking you to type your old password first, passwd prevents somebody from walking up to a terminal that you left yourself logged into and then changing your password without your knowledge.
Unix makes you type the new password twice:
% passwd Changing password for sarah. Old password:tuna4fis New password: nosSMi32 Retype new password: nosSMi32 %
If the two passwords you type don't match, your password remains unchanged. This is a safety precaution: if you made a mistake typing the new password and Unix only asked you once, then your password could be changed to some new value and you would have no way of knowing that value.
Even though passwords are not echoed when they are printed, the Backspace or Delete key (or whatever key you have bound to the "erase" function) will still delete the last character typed, so if you make a mistake, you can correct it.
Once you have changed your password, your old password will no longer work. Do not forget your new password! If you forget your new password, you will need to have the system administrator set it to something you can use to log in and try again.
 And if you are the system administrator, you'll have to log in as the superuser to change your password. If you've forgotten the superuser password, you may need to take drastic measures to recover.
If your system administrator gives you a new password, immediately change it to something else that only you know! Otherwise, if your system administrator is in the habit of setting the same password for forgetful users, your account may be compromised by someone else who has had a temporary lapse of memory; see Password: ChangeMe for an example.
After you have changed your password, try logging into your account with the new password to make sure that you've entered the new password properly. Ideally, you should do this without logging out, so you will have some recourse if you did not change your password properly. This is especially crucial if you are logged in as root and you have just changed the root password!
At one major university we know about, it was commonplace for students to change their passwords and then be unable to log into their accounts. Most often this happened when students tried to put control characters into their passwords. Other times, students mistyped the password and were unable to retype it again later. More than a few got so carried away making up a fancy password that they couldn't remember their passwords later.
Well, once a Unix password is entered, there is no way to decrypt it and recover it. The only recourse is to have someone change the password to another known value. Thus, the students would bring a picture ID to the computing center office, where a staff member would change the password to ChangeMe and instruct them to immediately go down the hall to a terminal room to do exactly that.
Late one semester shortly after the Internet worm incident (which occurred in November of 1988), one of the staff decided to try running a password cracker (see Chapter 19) to see how many student account passwords were weak. Much to the surprise of the staff member, dozens of the student accounts had a password of ChangeMe. Furthermore, at least one of the other staff members also had that as a password! The policy soon changed to one in which forgetful students were forced to enter a new password on the spot.
Some versions of the passwd command support a special -f flag. If this flag is provided when the superuser changes a person's password, that user is forced to change his or her password the very next time he logs into the system. It's a good option for system administrators to remember.
 The control characters ^@, ^C, ^G, ^H, ^J, ^M, ^Q, ^S, and ^[ should not be put in passwords, because they can be interpreted by the system. If your users will log in using xdm, users should avoid all control characters, as xdm often filters them out. You should also beware of control characters that may interact with your terminal programs, terminal concentrator monitors, and other intermediate systems you may use; for instance, the ~ character is often used as an escape character in ssh and rsh sessions. Finally, you may wish to avoid the # and @ characters, as some Unix systems still interpret these characters with their ancient use as erase and kill characters.
One way to try out your new password is to use the su command. Normally, the su command is used to switch to another account. But as the command requires that you type the password of the account to which you are switching, you can effectively use the su command to test the password of your own account.
% /bin/su nosmis password: mypassword %
(Of course, instead of typing nosmis and mypassword , use your own account name and password.)
If you're using a machine that is on a network, you can use the telnet, rlogin, or ssh programs to loop back through the network to log in a second time by typing:
% ssh -l dawn localhost dawn@loaclhost's password: w3kfsc! Last login: Sun Feb 3 11:48:45 on ttyb %
You can replace localhost in the above example with the name of your computer. This method is also useful when testing a change in the root password, as the su command does not prompt for a password when run by root.
If you try one of the earlier methods and discover that your password is not what you thought it was, you have a definite problem. To change the password to something you do know, you will need the current password. However, you don't know that password! You will need the help of the system administrator to fix the situation. (That's why you shouldn't log out?if the time is 2:00 a.m. on Saturday, you might not be able to reach the administrator until Monday morning, and you might want to get some work done before then.)
The superuser (user root) can't decode the password of any user. However, the system administrator can help you when you don't know what you've set your password to by using the superuser account to set your password to something known.
If you are running as the superuser (or the network administrator, in the case of NIS+), you can set the password of any user, including yourself, without supplying the old password. You do this by supplying the username to the passwd command when you invoke it:
# passwd cindy New password: NewR-pas Retype new password: NewR-pas #