Hackers Beware

Chapter 8. Password Security

When scanning the table ff contents, you might wonder why a whole section is dedicated to password security. After all, the subject of passwords is a fairly straightforward one and everyone knows the value of having strong passwords.

First, protecting yourself from password cracking is not as straightforward as you might think. There are many ways password cracking can be performed and many ways cracking techniques can be used to bypass good security safeguards. Second, I have found that few users truly understand what it means to have a strong password. Most people do not understand why passwords are so important and why they need to be protected. Interestingly enough, when you ask most users why they have a password and why they have to change it, the typical response is, “To make IT happy” or “Corporate security forces me to do it.” The real reason is to keep a system secure and safe. This chapter emphasizes that when users understand why certain security measures are put in place, the chances of them adhering to those measures increases tremendously.

Before looking at the history of passwords and where the trends are moving in the future, this chapter starts by taking a look at how the industry has arrived where it is today. A milestone of having strong passwords is having a good foundation or password policy. We will look at the topic of password policies and why they are important by looking at a typical attack. Then, we will cover passwords from many different angles— what they are, why we need them, and what constitutes a strong password. Finally, we will finish the chapter by covering password attacks. This chapter will lay the foundation for the remaining chapters in this section: Chapter 9, “Microsoft NT Password Crackers,” and Chapter 10, “UNIX Password Crackers

Typical Attack

To emphasize the importance of passwords, let’s look at a common way an attacker breaks into a system. Two of the most common weaknesses in a company are weak passwords and uncontrolled modems on the network. So, it only makes sense that a popular way to exploit a system is by combining the two methods. Let’s briefly go over the attack.

An attacker gets the phone number for the company from a web site or by calling an operator. After he obtains the number, the attacker runs a war dialer program against the base number. For example, if the general number is 555-5500, the base number is most likely 555-55xx. A war dialer is a program that dials a list of numbers looking for a modem to answer. When a modem answers, it records the phone number of the line that contains a modem. War dialers are covered in detail in Chapter 3, “Information Gathering.”

Now that the attacker has a list of modems, the attacker dials these numbers; and when prompted for a user ID and password, he tries to guess this information. The attacker is successful because so many companies have common accounts with either weak or no passwords. For example, a common logon is guest or temp with no password. Also, many vendors’ software have built-in accounts with default passwords that no one changes. Another common trick used by administrators is to log on as administrator or root, with the company name as the password. Because many people use these accounts, the company usually picks something that is easy to remember. This might seem like an oversimplification, but it’s not. It is a reflection of the current state of affairs when it comes to passwords. When I perform penetration testing, it is amazing how many times I am successful with the preceding scenario.

Before moving on, please read the following sidebar that addresses the legal issues surrounding password cracking.

Legal Implications

It is important to emphasize the legal implications surrounding password cracking. Even if you are working at a company and think that you are empowered to crack passwords, you should always get written permission before doing so. If in doubt, get permission. If you do not get permission, you could find yourself in a lot of unexpected trouble.

In a real world example, a security expert was working at a large, Fortune 100 company and thought he was authorized to perform password cracking. Without getting formal authorization, he started password cracking on a regular basis because he thought it was his job. When the company discovered what the expert was doing, it sued him and won. The individual received a deferred 90day jail term, 5 years of probation, and 480 of hours of community service. The security expert’s legal fees were more than $170,000, and he was ordered to pay over $68,000 in restitution.

The next time you think that it is okay to run password cracking or security tools against your company’s system, make the extra effort to get prior permission in writing. What you view as part of your job, management might view as malicious and unacceptable behavior. For additional details on this case, see http://www.lightlink.com/spacenka/fors/intro.html.

The Current State of Passwords

As I’ve mentioned, the current state of passwords in most companies is poor. The way most companies set up their security, passwords become the first and only line of defense. In cases where they are weak, it creates a major hole that an attacker can use to compromise a system. If an attacker can compromise a user’s password, he receives full access to the system. This creates a major problem. Even if passwords are very strong, they should not be the only line of defense.

One of the main reasons passwords are the only line of defense is that companies do not have access control lists, which limit who can access what information and provide other security measures. A typical access control list states which individuals have access to a file or folder and what permissions they have—like read, write, execute, and so on.

For a company to properly secure information, it cannot rely on just one defense mechanism; it must have multiple levels of security, which is commonly referred to as defense in depth. The argument for using this policy is that the more defense mechanisms an attacker must go through,

the less his chance of success; also, by the time an attacker successfully gets through all of the measures, your chances of detecting him should be high.

Another problem with passwords is that most systems and software have default passwords or built-in accounts that few people change. This problem has been getting better, but there are many systems that have default accounts and/or passwords still enabled. Administrators do this for three main reasons:

•They are not aware that defaults exist and cannot disable them.

•From a failsafe standpoint, they want the vendor to be able to access the system if a major problem occurs, and therefore they do not want to lock the vendors out by changing the passwords.

•Most administrators want to guarantee that they do not get locked out of the system themselves. One way of doing this is to create an account with an easy-to-remember password. Another thing they do is share it with other people or write it down, both of which create major security holes in the system.

Two other password trends are to have passwords that are trivial to guess or have no password at all. I frequently run across accounts that have no passwords. At least with any easy-to-guess password the attacker has to perform a little work, but with an account that has no password, he doesn’t have to do anything.

To illustrate how bad the problem is with easy-to-guess passwords, let me give you another example. I was at a company performing a security assessment and one of the salespeople approached me and asked what I was doing. I explained to him that I was performing a security assessment and was looking at various aspects of security across the company. In the course of the conversation, he asked if I was going to check passwords and try to crack them. After I told him that I was, with all seriousness, he told me that I was going to have some difficulty trying to guess his password. He then turned around, stretched his arms over his head, took a practice golf swing, and said, “I think I am going to try to get in nine holes after work today.” Do you want to try and guess what his password was? GOLF!

This being so humorous, I started tracking statistics when I performed security assessments and began to notice an interesting trend. Eighty percent of all the salespeople that I came in contact with had a password of either golf or bogey. If you know the user ID of a salesperson’s account and you want to get into his account, try these two passwords and your chances of success are very high. Despite the humor, this information concerns me. Not only do people have weak passwords, but they actually think their passwords are fairly secure.

There is one additional fact worth mentioning (just in case I have not depressed you enough): password change interval. Most companies I have had experience with have passwords that either do not expire or expire every six to nine months, which is too long. If the interval is shorter, even if an attacker guesses your password, he only has access to your account for a short time before you change the password and lock him out. With a long interval, when an attacker guesses a password, he has access to your account for a very long time. The general rule of thumb is that your password change interval should be less than the time it takes to brute force a password. So if your password can be brute forced in four months, than your passwords should change every three months.

To better understand our current situation regarding passwords, let’s take a brief look at the history of passwords. After all, we do not want to repeat the same mistakes. Then, we will cover the future of passwords and what is waiting for us on the horizon

History of Passwords

When companies first started buying computers in the mid-1980s, people quickly realized that they needed to protect the information they entered into their computers. An easy way to secure the information was to have users identify themselves with a user ID when they logged on to the system.

This was a good start, but because it was fairly easy to figure out someone’s user ID, little could stop someone from logging in as someone else. Based on this problem, passwords were added to the user ID. With this additional security step, users not only provided their user ID to identify who they were, but they also provided a password that was known only by them, to prove their identity to the system. What did most users do? They did the same thing most people do with access codes such as ATM cards or alarm systems; they picked something that was easy to remember.

As you can imagine, this created a major problem, because the whole purpose of a password was to uniquely identify yourself to the system. The assumption was made that if you correctly provided or knew Eric’s password, you must be Eric. So, because people were using family members’ names and birthdays as passwords, anyone who knew anything about a person could probably guess that person’s password in ten guesses or less.

For example, I know a little bit about John, so let’s try the following:

•Sally. His wife’s name.

•George. His child’s name.

•Randoff. His wife’s maiden name.

•Tennis. A sport John likes.

•March 9. Date of John’s birthday.

•Waterfall. A poster that John has in his office.

•Alpha. The brand of computer John uses.

Any of these possibilities has a high chance of being John’s password. In some cases, it could be worse, where John would have a password of John, johnpass, or john1234.

Companies quickly realized that trusting users to pick their own passwords was not a good idea, so they assigned passwords to users. These passwords were usually hard-to-guess passwords and did not contain any known words—for example, w#hg@5d4%d10.

Users were not very happy with this alternative for two main reasons: the passwords were hard to remember and they were confusing. After typing a random string of characters for several weeks, it becomes easy to remember, but initially it is very difficult. So what did everyone do? They wrote down their password.

One of my first jobs out of college, was for a defense contractor that had access to sensitive government information. For the contractor to maintain the contract, it was subject to random security reviews. A security review consisted of an unannounced walk-through of the facilities in the evening, to validate that the company was adhering to the security standards.

One common check was to look for passwords that were written down. Because most users wrote their password somewhere, just in case they forgot it, this turned into a battle to see how well the user could hide it and how well the reviewers would search to find it. The creative lengths users would go to always amazed me. Some users would hide their password in their rolodex under a certain name. One clever individual even wrote it on the bottom of his shoe. I still remember the frustration when the user came in one Monday and couldn’t log on the network, because he bought a new pair of shoes and forgot to transfer over the password! The key to remember is that users will get creative, but the creativity is limited, which means that if an attacker wants to find the password, he can.

The second problem with random passwords is that they are confusing. With the password Ol10, it is difficult to determine which of the characters is a letter and which is a number.

To fix the preceding two problems, companies still used machinegenerated passwords, but with a little more thought. They either did not

use confusing letters or they used only one—for example, no passwords containing the letter L or the letter o. This way, you would know that confusing items were really numbers. Usually, letters were left out because there were a lot more letters than numbers to choose from.

The second thing companies did was they added vowels in key spots, so that the passwords were not dictionary words but were still pronounceable, like gesabaltoo. This made a password easier to remember because a user could at least sound it out. Another trick was to take dictionary words and replace letters with numbers—for example, ba1100n, where the letter l is replaced with one and o is replaced with zero. These, however, were quickly discarded because it is fairly easy to write a program that checks for these permutations.

Despite these innovations, users still wrote their passwords down, because they had difficulty remembering them. Most companies eventually gave up and allowed users to pick their own passwords. The main concern was that users would use guessable passwords. Within a short time period, everyone’s concerns came true when companies realized that most users picked easy-to-guess passwords.

In response, companies issued password policies that all users had to sign. These policies clearly stated that passwords must be hard to guess and other details. In most companies, these policies had little impact on the strength of passwords.

Finally, companies decided that if users were going to pick their own passwords, there needed to be some way to automatically enforce the password policy. This was done by utilizing third-party programs that could be used to check a user’s password; if it did not adhere to the policy, the program would force the user to change it. This improved the strength of the password, but because they were harder to remember, people started writing their passwords down again.

Future of Passwords

Today, most companies are either fighting the endless battle with users or are using one-time passwords. One-time passwords can be expensive but provide a nice alternative. With a one-time password, a user is given a device that generates a new password at certain time intervals, usually every minute. This device is keyed with the server, so that both devices generate the same password at the same time. Now, when a user wants to log on to the system, she looks at the display and types in the password. This works nicely because a user has a different password each time he logs on. Even if an attacker gets the password, it is only good for one minute.

In addition to time-based, one-time passwords, there are devices that support challenge response schemes. With these devices, the user provides his user ID to the system, and the system responds with a challenge. The user takes this challenge and enters it into the device. The device then provides a response that the user enters as the password. One issue with this scheme is that the device the user has to carry with her must allow her to provide input to the device. This tends to make the devices more expensive. A problem with both types of device is that they are subject to getting lost or stolen. With these devices, users do not have to remember passwords, but they do have to remember to keep the device with them at all times. If you look around and see how often people forget their badges, you can better understand the scope of the problem.

Another technology that has been out for a while, but gets a lot of resistance, is biometrics. Biometrics uses human features to uniquely identify an individual. For example, everyone’s fingerprint is different, so why not have a fingerprint reader at each machine to determine if the user is really who he says he is? The following web site contains detailed information on biometrics and how some of the techniques work: http://www.biometricgroup.com/. The following are some of the common biometrics that are being used:

•Fingerprint scan

•Hand scan

•Retinal scan

•Facial scan

•Voice scan

Each of these techniques has different reliability, costs, and risks associated with it.

Some of the advantages of biometrics are that it requires nothing for the user to remember, and the data is hard to forge. Both are key requirements for good authentication systems. Biometrics are also with a user at all times and are very difficult to lose.

One of the biggest complaints about biometrics is invasion of privacy. Most people are very concerned about having their personal information stored and archived on servers. A lot of people view this as the first step toward large government databases, which would lead to no privacy. If you think about it, it can be very scary. Think of a system where someone can identify you anywhere and any time. Another concern is safety. Most people are not comfortable with someone scanning their eye, especially because this equipment has not been around long enough to know the long-term effects. The last problem is cost. Currently, having each user log on to the system with a password does not cost a lot of money. With

biometrics, a reader has to be attached to every single device that a user could log on from. This means, if there are over 1,000 machines at a company, every single machine, including machines that are at employees’ homes that are used to log on remotely, must also have these devices installed. As you can imagine, the price tag for implementing this can easily exceed a million dollars for a mid-size company.

As with any system, currently most companies have decided that the disadvantages outweigh the advantages and therefore are not using biometrics. However, as passwords get easier and easier to crack, you might see more and more companies looking towards biometrics as the solution.

What Really Works: A Real Life Example

As you can see from looking at the history of passwords, most of the things companies have implemented to protect passwords do not work, which can lead to a high level of frustration for the company and the end user. Based on the frustration factor, one of the most common questions I get asked when I lecture on this topic is, “What can we do, or what do you recommend to fix the problem?” If I merely told you what I have found to work, you might not believe me; so I will give some facts to back my position.

When I headed up internal security for a fairly large company, one of the problems was passwords. When I first started, we scanned everyone’s passwords and were able to crack 80 percent of the passwords in ten minutes and 95 percent of the passwords in fewer than five hours. This was a huge security hole, so I put together a password policy that clearly stated that all passwords must contain at least one letter, one number, and one special character and should not contain a word.

Two weeks later, I re-ran the password cracker and was able to crack 78 percent of the passwords in ten minutes. As you will see in the next section, password policies are important from a corporate and legal standpoint, but in some cases have little affect on the user. Next, I decided to send emails to users that consistently had weak passwords to explain to them the problem and asked them to pick a stronger password. We also sent them directions on how to change their passwords and said that if they needed any help, they could call us.

Again, we ran the password cracking program and were still able to crack 77 percent of the passwords. As you can tell, we were not making a lot of improvements. Then, we decided to post paper messages on their monitors, so that we knew that they saw it. Besides causing several people to pull me aside and curse and verbally abuse me, it had no effect. Users became very upset because they felt that we were becoming big brother and taking too much control. If you enjoy being screamed at, this should be top on your list.

Finally, I hit on something that worked. I realized that most people at the company did not understand or appreciate security. I received permission from the CIO to have mandatory security awareness sessions.