Building blocks to security: Passwords -- the first line of defense

Unix Insider –

Passwords -- the first line of defense and the oldest form of security on Unix systems -- might seem a very tired topic. You might even think there would be nothing left to say about passwords but, even today, people are making the same basic mistakes -- choosing obvious passwords, writing passwords down, or sharing passwords -- that they were making 10 years or more ago. When even a systems administrator is likely to set a user's password to "password" whether by intention or because the user has requested it, one has to wonder how much of our new awareness of the importance of system security has impacted day-to-day operations.

Even if user password choices are much the same as they were 10 years ago, however, two dramatic changes have taken place. For one, the number of passwords and other secret codes that each of us has to remember has increased dramatically. Given online banking, online bill paying, access codes for voicemail and unlocking cell phones, secret codes for ATMs, passwords for logging in to Websites, and security codes for offices and maybe even homes, the fact is that we are reaching the point at which we simply have too many secret codes to remember without some kind of crutch, whether it be paper or something else altogether. We run the risk of being locked out of our various accounts and maybe even our homes and offices by an excess of secret codes. If we set all of our passwords the same or write them down to compensate, we introduce risks of another kind.

The second change that has occurred -- the increasing use of security tools -- is a boon to security. Usage of tools -- such as personal firewalls, VPNs, and ssh -- that limit password and data exposure has roughly paralleled the growth of telecommuting. Telecommuters can now securely log in to work systems and update program and data files without fear that they are risking their company's code or Internet presence.

Balancing these two changes -- the password explosion and the general availability of security tools -- against each other, where do we stand with respect to the vulnerability of passwords today? Before we answer this question, let's review why passwords are vulnerable in the first place.

Basic authentication

In the simplest and most common form of authentication (the process of verifying the identity of an individual), only the user's login name and password are used. The assumption is, of course, that only the intended user knows the password. Since the username is effectively public (i.e., it is almost always the user's email address as well and printed on business cards), the secrecy of the password is the only thing that stands between an imposter and the user's files.

Typical computer users, even today, seem to think that some "clever" substitution of letters (e.g., replacing the letter "o" with the digit "0") or a keyboard pattern (e.g., "qwerty") are sufficient to make their passwords hard to guess. In fact, there are extremely few, if any, tricks of this nature that haven't been thought of by those who seek to break passwords. A safer bet is to assume that any clever scheme that you can imagine has already been thought of by hundreds, if not thousands, of people.

Passwords are vulnerable for two basic reasons: 1) they are often passed over networks in clear text, and 2) given adequate resources (knowledge, tools, and compute power), they can be guessed or broken.

Even if your password is a "good password" according to the most stringent security guidelines, it may still be vulnerable. Any Unix user with the root password to the box on his desk can sniff passwords off the network and many users still exclusively use tools like telnet that transmit passwords in clear text. One of the oldest and simplest hacking tricks in the book is to use a sniffer to grab telnet packets off the network and extract the username and password. You don't even need any special tools, which typically are built into the operating system.

The worst passwords are those that are easy to guess. If you make your password the same as your home address (e.g., 7610Park), anyone who knows your address and knows your habits might guess it. If you're a sports fan or love classical music -- in fact, if you have any obvious interests -- you should be especially careful to avoid using names and words related to these interests as passwords.

Further, what can't be guessed by a knowledgeable human might be guessed by a piece of software. The most mundane form of password breaking is to guess every possible password. This might seem impossibly difficult, but if a single clue exists (for example, knowledge that passwords are whole words and numbers), the field of possibilities may go down tenfold or even a hundredfold. A piece of software capable of making half a million guesses a second might become surprising good.

Dictionary attacks and attacks that try all of the clever tricks that many of us seem to think no one else has thought of, have an even better chance of success. The classic tool for checking passwords, Crack, runs through numerous filters and permutations in trying to break passwords.

In addition to network sniffing, passwords can be stolen off a system if the user opts to allow "helpful" software to remember the passwords for him. This seems to be especially true of Windows systems on which tools like Internet Explorer frequently offer to remember passwords. The risk depends on how accessible the system in question will be. Stored passwords can be scraped up and displayed in clear text by special tools designed for just this purpose (though probably intended to assist a user who can no longer remember the password after months of not having to enter it). It is a much better choice to never allow any application to save a password for you.

Password precautions

In spite of how many cautions you will see again against writing passwords down, keep in mind that it makes a big difference where and how one writes them down. If a user tucks a slip of paper into his wallet on which he has written a clue that reminds him of a password (e.g., he writes "saturn,breakfast" when the password to saturn is "egzNhamm"), the risk is extremely small. It's the user who leaves the root password to a system written on a slip of paper tucked underneath the keyboard that shows bad judgment.

A good piece of advice that you should give to every computer user is: Don't choose passwords that you can't remember. I've been surprised at how many times I have picked a password I thought I couldn't possibly forget and then, the next day, couldn't possibly remember. Be smart, not clever, when deciding on how to remember multiple passwords. Clever implies that passwords are "cute" in some way. Smart implies that you have a scheme for remembering multiple passwords that will not risk the whole set if one password is compromised.

Software to the rescue

One of the technologies which promises to change the landscape with respect to passwords is called single sign-on (SSO). SSO systems allow a user to log in once. Subsequent to this initial login, all additional connections are carried out through the client software. The software negotiates connections to other systems on the user's behalf. In other words, the passwords to other systems are managed by the software, not the user. The user can, therefore, access many systems and services without having to remember multiple passwords or set all passwords the same. On the other hand, a compromise of an SSO system in which an unauthorized person learns the single password that the user needs for initial login leaves all of the systems vulnerable, just as if the same passwords had been used for all of the systems. SSO systems that add some other credential to the login process (e.g., a SecurID or a smart card that the user must have on his or her person when logging in) go a long way toward avoiding this vulnerability. One such SSO system is Tivoli's Global Sign-On (see Resources for a link.). Passwords for other systems are stored in a local database in encrypted form, which is what is passed over the network.

Another good strategy, readily available and inexpensive, is to use ssh. (See Resources for an article link.)rlogin,

scp

, and

rsh

) used by some Unix users for many years. Free client software is available from a number of sources -- PuTTY and the TeraTerm Pro SSH module are free clients available for Windows users. (See Resources for links.)

Systems management

Unix systems can be managed in such a way as to reduce the risk that bad or otherwise vulnerable passwords introduce. If your password software can be configured to enforce restrictions on passwords (e.g., disallowing permutations on the username, requiring a certain number of characters, or requiring some nonalphabetic character), make sure that these restrictions are enforced. These restrictions go a long way toward forcing users to select passwords which are considerably better than average.

It also helps to ensure that password aging is used and that your organization has a reliable method of disabling accounts whenever someone leaves the organization for any reason. I am astounded at how many organizations do not shut down accounts when individuals leave.

Another technique is to limit the number of logins possible on particularly critical systems. Almost no one should have access to your firewalls and DNS servers. If you employ a standard password file and copy it to various systems, you might, instead, keep two or more "standard" versions of your password file so that the more sensitive or critical systems will be better protected. It may be a bit more work to maintain multiple versions of password files, but the effort will probably pay off. If you're rdist'ing

/etc files

, it's only a little more work to define two sets of servers -- those that get all of the passwords and those that get a pared-down list.

Give the root password to almost no one -- two or three authorized systems people at an average site are probably quite enough. Deputies can be called into service as needed. The risk associated with password compromises is dramatically increased when the password in question is the superuser (or "root") password. One of the trends that helps to reduce the risk associated with unauthorized superuser access is "sudo". The sudo utility is used to give users limited root access to individuals who require temporary root access or the ability to run only certain commands. One of the prime advantages of sudo is that you never have to give out the root password (a sudo-authorized user is required to enter his own password when issuing sudo commands) and you can withdraw the user's access at any time. Unlike a user who has been given the root password, users with root access via sudo cannot pass on the privilege to other users except by sharing their own passwords. If someone with sudo access leaves the organization, you don't even have to change the root password to guard against the possibility of that person logging back in. You just remove the associated username from the

/etc/sudoers

file (the file that determines who is able to use to sudo command and what Unix commands they are allowed to execute).

If you're managing a system:

• Use good judgment in setting up (and writing down) passwords
• Encourage users to do the same
• Configure and use sudo
• Configure and use ssh
• Look into SSO solutions
• Enforce password controls
• Use password aging (require changes every 3-6 months)
• Don't issue obvious or simple passwords, even temporarily

The basic battle still to be won in the field of computer security is that being waged between security and convenience. Far too many users and system administrators compromise security to make it easier for themselves and others to get their work done. The reverse is unfortunately true; it's hard to make systems more secure without sacrificing some level of convenience. If I didn't feel that I had to lock my car, I could leave my key in the ignition and would never lock myself out. Because my car would be at risk if I did this, I have to carry and keep track of my keys -- a responsibility that backfires in some way several times a year. Because I manage systems for which the security is important, I have to implement passwords. Several times a year, if not more often, I will be unable to access a system because I have forgotten or don't know a password that I need. At these particular moments, I wish my password were "password." Most of the time, I'm glad it isn't.

Discuss this article in the Web Security Q&A discussion on ITworld.com.

Resources

• Tivoli's Global Sign-On: http://www.tivoli.com/products/documents/whitepapers/gso.html
• "Make SSH do more," Jon Lasser (LinuxWorld.com, April 2001): http://www.itworld.com/Comp/2384/LWD010410sshtips/
• PuTTY: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
• TeraTerm Pro SSH module: http://hp.vector.co.jp/authors/VA002416/teraterm.html

This story, "Building blocks to security: Passwords -- the first line of defense" was originally published by ITworld.