6.1 Passwords

The Achilles heel of most networks is their reliance on passwords. There are alternatives to passwords, such as one-time passwords and biometrics, but these solutions may not always make sense in all environments, especially when a risk analysis determines that the extra cost involved with these solutions is not justified by the security required of the application.

Passwords, on the other hand, are virtually universal in application. Regardless of the security required or purchased for your installation, it is a sure bet that, at a minimum, passwords are provided as a security mechanism. The reliance on passwords makes them especially important to the security of information but, unfortunately, poorly chosen passwords and poor password security are the single biggest risk that most organizations face.

Organizations that rely on passwords for authentication face a number of associated risks associated. The first is that people tend to choose weak passwords. A survey performed by a British ISP revealed that 47 percent of people choose passwords based on family names or significant dates in the family. After all, who would ever guess that your password was your youngest daughter's name with a couple of numbers after it? Another 32 percent had passwords that were based on sports stars or other celebrities. Thus, nobody would ever make an association between your Simpson's screen saver and your log-on password. A full 11 percent of users reported passwords that were in some way representative of an alter fantasy ego of the user, such as "stud," "sexy," "goddess," etc. Only 9 percent of users reported using passwords that were considered cryptographically strong; that is, comprised of random characters with upper and lower case characters combined. With just a bit of knowledge about a person, a hacker could, within a short time, compromise 91 percent of all user accounts.

Why do people choose such poor passwords? Most users are not trying to lessen the information security policy of the organization on purpose. They are simply trying to pick a password that they are likely to remember. The problem is compounded by requiring users to have multiple passwords for different services on the network and by requiring that users change their passwords on a regular basis. If we force users to create truly random passwords, then they end up writing them down. In other words, users choose poor passwords because they do not have the memory capabilities of a computer.

Network security has progressed to the point were most applications — Telnet, POP3, and FTP excluded— do not send plaintext passwords over the network. Furthermore, passwords are not generally stored in plaintext on an application server. The risk of someone gaining access to the password file and learning everyone's passwords is too great. Thus, anyone obtaining a password file must still go through the task of determining what that password was. Passwords are generally not encrypted as we might do in a VPN; instead, passwords are hashed using common hashing algorithms such as MD5 or SHA-1.

Using hashes as a way to store and transmit passwords ensures that someone cannot simply look at the hash and determine what the password is. It does not, however, render the passwords immune to attack. If, for example, our passwords only have four characters, there are a finite number of combinations on a keyboard that those four characters could be. It would be a small matter for a computer to simply generate random combinations of four characters, hash them, and examine the output. If the hash output from the randomly generated characters matches the captured hashed password, then we can conclude what the password is. The more characters included in a password, the longer this process can take; but given enough time, any captured password can be discovered in this manner.

This process can be significantly speeded up with an understanding of user psychology. Knowing that users will use terms that are related to family, sports, television, and fantasy images of themselves, of all the trillions of combinations that a password could be, we simply try the most popular hundred thousand variations of family names and sports stars. Entire dictionaries can also be included in our hash files, allowing us to break most passwords based on common choices in virtually no time. It is only those 9 percent of cryptographically strong passwords that cause a password-cracking program any trouble.

Based on this information, we cannot trust users to create their own passwords without some guidance. Instead, we must offer assistance in the creation of secure passwords. One alternative is for network administrators to generate passwords on the behalf of users and trust the network administrator to choose secure options for the users. This is not ideal for three reasons. The first is that it creates an unnecessary amount of overhead on the part of the network administration staff. The second reason is that a user could reasonably argue that the use of a password for identification is flawed from the beginning in that at least one other person knows the password. Ideally, network administrators can reset password for users or create an initial password, but user passwords should be encrypted even from the knowledge of the network administrators. Finally, users do not do well remembering passwords that are not of their own creation. A cryptographically ideal password generated by a network administrator will simply end up being written on a post-it note and stuck under the keyboard or, worse yet, on the side of the computer monitor.

Software does exist to allow users to evaluate or create their own secure passwords. The first class of software can be broadly categorized as a password creator. While better than allowing a network administrator to create the password, this creates the same problem — the user has no ownership of the password and will again be forced to take steps to remember the password. The second class of password software is known as a password checker. This software runs in the background or as part of the password creation/changing software interface and gives users an indication of the relative strength of their password. Thus, if a user were to pick a password such as "Patriots03!," the password checker would recognize that the majority of the password was based on a common name and warn the user that he had chosen a weak password. Because the user is still allowed to create the password, there is a better chance that he will come up with a secure password that can be easily remembered. When evaluating an operating system or other access control mechanism, the existence of password checking software would be advantageous.

The question still remains, however, if an organization is forced to rely on passwords for authentication, how can users easily remember to choose a good password that seems random? The most helpful technique I have found in this regard is to teach users how to create mnemonic-based passwords. Instead of using a password, users create a passphrase that they then condense into a password. For example, if a user is familiar with Lincoln's Gettysburg address, the following phrase may be familiar to them, "Four score and seven years ago our forefathers…." Clearly, nobody wants to type this in each morning as they log on, but by borrowing the first letter from each word, the password "fsasyaof" Is generated. Clearly, that is not a dictionary word. Mixing up lower case and upper case characters can make a password more complex for systems that recognize the difference between the two, such as "FSaSyaoF." This password can be made more complex by including numbers instead of letters in some parts of the password, such as "420a7yaof." The inclusion of special characters also greatly increases the security of a password. While not all access control mechanisms support special characters, if they did, the following password would be easy enough to remember: "4@)a7yaoF." In this case, some of the numbers were replaced with the special characters accessed via the shift key on most keyboards. To someone unfamiliar with the phrase that generated this password, this would be a difficult password to guess. Instructing users in this method of password generation and allowing them some time to create some in a group setting to ensure that the method has sunk in can create fairly strong passwords created on a regular basis using any key phrase relevant to the user.

Regardless of the method used for creating passwords, passwords can be sniffed as they pass over the network medium. As mentioned, most security-conscious applications will at least go through the effort of hashing the passwords using MD5 or SHA-1 hashing. Using a mnemonic password is not going to prevent someone from using a password hacker on an encrypted password and eventually breaking the password — a good password will, however, greatly increase the time required to break it. Just for comparison, almost any password that is based on any common dictionary word, name, or sports team will be revealed by password cracking software in well under ten seconds. Passwords such as 4@)a7yaoF can take weeks to months to break, depending on the hardware on which the password cracking software is running.

Before passwords are exchanged between client and server, if there is the opportunity, any form of IP encryption available should be used. This ensures that even the password hash that is being sent is itself encrypted. Someone capturing a password encrypted using SSL will first have to crack the SSL secret key used to encrypt the password and then start working on the hashed password itself. This process would take long enough to convince all but the most determined attacker that it was not worth the effort.

It should also be noted that some applications do not encrypt or hash passwords at all. Notorious in this regard are common applications such as POP3, Telnet, and FTP. As such, these applications should always use unique passwords that are unlike any passwords used elsewhere by the user. In each of these instances, established protocols such as SSL, SSH, and SCP for the three protocols, respectively, can all be used to encrypt the sessions themselves before the passwords are sent. Most client software such as e-mail, terminal, and file transfer software support these more secure protocol versions as a configuration option on the server and as part of the client.

Eventually, even the most cryptic password can be compromised. For this reason, it is standard operating procedure to mandate that passwords be changed on a regular basis. The timeframe used for changing passwords is one that is often troubling for those implementing a security policy. Making the timeframe too long increases the chance that bad passwords will be discovered and used. Making the timeframe too short annoys users and encourages them to simply re-enter the same old password as the new password. Keeping a password history in the access control system that prevents users from reusing any of the last four, eight, ten, or any number of configurable previous passwords can prevent this behavior. Users quickly figure this out and will then rapidly change their password a number of times in order to cycle back to the original password. This behavior can be prevented by implementing a hold-down timer in the access control system that prevents users from changing passwords more than once in any given time period. For example, users can be prevented from changing their passwords more than once a day. Users will then circumvent this by choosing passwords such as "password01," "password02," "password03," etc. Each password is then only slightly different from the previous one — a dubious increase in security. Because the ability of users to confound even the most well-intentioned security policy can never be underestimated, it is always more productive for security personnel and network administrators to work with the human factor and establish fair time intervals for the mandatory changing of passwords.

The best guideline for the changing passwords depends on the sensitivity of the user role. Normal network users may be fine only changing passwords on a three- to six-month basis. Users with administrative rights on the network should be changing their passwords on a two- to three-month basis. Note that the goal of changing the administrative password is to prevent anyone who has somehow discovered administrative passwords from continuing to use them on the network. Simply changing the password, however, is not sufficient to ensure the security of servers. Unless user behavior has changed as well, it is a good bet that whoever learned the password the first time will simply learn it again. Furthermore, any competent attacker will promptly install a backdoor to access a server that does not rely on administrator access at all.

6.1.1 One-Time Passwords

While steps can be taken to ensure that a password is difficult to guess or discover using specialized password cracking software, the fact remains that the longer a password is valid, the greater the chance that someone will discover what that password is. Ideally, we would like to use passwords that are only good for a single access. We have seen, however, that user resistance to having to create a new, cryptographically strong password each day would simply be unacceptable.

One-time passwords (OTP) is an authentication system that attempts to implement our desire for short-lived passwords but at the same time be fairly user friendly. In its most pristine form, one-time passwords can simply be a printout of a number of passwords. Users simply work down the list when logging on. The first time they log on, they enter the first password. The second time they log on, they cross off the first password and use the second password. Whatever service is authenticating the user has a similar list and performs the same procedure as the user, incrementing the valid password to the next one on the list each time the user logs on.

This simple form of one-time passwords is clearly no better than normal passwords. Should the password list be lost or photocopied, an attacker would still have the same access to user information if the user simply posted his password on his computer monitor. Instead, OTP is implemented using some sort of electronic card or token. The card itself contains a microchip and a quartz clock that maintains synchronization with the server. The microchip and the server both contain a program that will ensure that the card and the server generate the same password as long as the clocks are synchronized. By synchronizing the card or token with the server, both the card and the server will periodically create a new password on a 30- or 60-second basis. The system can be visualized by imagining that you and I had agreed on a simple code, and each hour we would change our secret code in a predetermined manner.

As there is still a risk of the smart card itself being lost or stolen, most one-time password systems employ two-factor authentication, utilizing a PIN to establish proper ownership of the card and using the card generated password for authentication to the access control system. While more secure than passwords alone, OTPs do suffer from the disadvantage of requiring additional hardware and software to support this function. Additionally, the cards occasionally lose synchronization with the server, thus requiring administrative intervention or additional software support to resynchronize the devices. Are they worth the extra effort? Your risk analysis should tell you that.