[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Lec 23




These are the notes for lecture 23

Mark



Title: Math 481/581 Lecture 23: UNIX Passwords

Math 481/581 Lecture 23: UNIX Passwords

© 1998 by Mark Hays <hays@math.arizona.edu>. All rights reserved.


In this lecture we'll discuss how standard UNIX passwords work, how to choose a good password, and why it is important to do so.


Introduction

As we've seen, UNIX is a multiuser, multitasking operating system. This means that multiple users can run multiple jobs at the same time on the same physical machine.

Each user of a machine must have an account on the machine. This prevents individual users from (intentionally or accidently) mucking around with each other's files, processes, etc. People without accounts cannot use the machine at all, which helps minimize chaos.

To access your account on a UNIX machine, you must first log in. Once you do this, you can access your files, run jobs, and make use of the machine in the usual fashion.

When you log in to a UNIX machine, you are prompted to type in your username -- this tells the computer who wants to log in. Next, the computer asks you to prove that this is who you are by prompting you for your password. If you give the correct password, the machine assumes that the person trying to log in really is you. The assumption is that the human Mark Hays is the only person who knows the password that goes with the username "hays". Therefore, any human who can produce the password that goes with the username "hays" must be Mark Hays. The process of establishing your identity to the computer is called authentication.

How does the machine know that the password you typed is correct? One way to do it is to store all of the username/password pairs in a text file. This is a lousy idea: if a malicious user manages to get a copy of the file, that user can become any user on the system. Instead, a slightly more roundabout approach is used.

The computer stores information about users in a file called "passwd". Aside from your username, full name, home directory, etc., this file contains your username and an encrypted version of your password. For example, if your password is:

   haha
it might be encrypted and stored in the passwd file as:
   XXqCWoBXvnjCg
There is an algorithm (modified triple DES) to generate the ciphertext (encrypted version) from the plaintext (what you type at the prompt) string; however, there is no known way to determine the plaintext from the ciphertext.

So what happens when you log in? Once you type in your username and password, the computer encrypts the password that you typed in and compares the result to the encrypted password corresponding to the username that you typed in. If they match, the computer "knows" that the person logging in "belongs" to the specified username. If the two don't match, the computer makes you try again.

For authentication purposes, it is important to understand that, as far as a UNIX machine is concerned, a user is a username/password pair. Your username is widely known (so that other users can send you email, etc), but your password should only be known by you (remember: even the computer doesn't know what your password is). Anyone in the world who knows your username and password on a UNIX system can do anything that you can do on that system. A malicious person in possession of your password can do all sorts of nasty things, including:

Create files Fill your account with kiddie porn and call the police. You will be immediately arrested by the police.
Alter files Insert undesirable messages into your dissertation, or change a '+' to a '-' here and there.
Remove Files Delete all of your files with /bin/rm -rf $HOME.
Send email as you Send an insulting note to Bill Clinton, CC'ed to the whole department.
Post news as you Similar to the above, except millions of people get to read it.
"Fix" your home page Redo your home page with insulting messages and sexually explicit materials. Billions of people can read it now.
Stepping stone Use your account to break into a Top Secret goverment computer. The intruder will appear to be you, for all intents and purposes. You will sit in jail (or worse) until things get straightened out.

Some people share their password with friends, etc. Here is a (far from exhaustive) list of what can go wrong:

I have heard users say "well, I don't care if my password is known because I don't keep anything important in my account".

Let us explore some of the flaws in this statement. Remember, UNIX is a multiuser operating system. In the math department, there are over 600 UNIX accounts. If an unauthorized person performs a crime in which departmental machines are involved, a number of things can happen (aside from deletion/modification of user files, sending of bogus email, posting of bogus news messages, etc.).

If the crime is severe enough, the departmental fileserver could be confiscated as evidence. In addition, the backup tapes could be confiscated to establish a timeline for the crime. The equipment would, of course, be returned. Eventually.

First, it would take a significant amount of time for the authorities to check through the several hundred thousand files on the server's disks. The other aspects of the investigation would also take time. Given the backlog in the court system, the trial and appeal process could take a couple of years. In other words, unauthorized use of a single account could result in two to four years of downtime for the other 599+ users.

Remember, all computers purchased through the University are state property. All of them. Unauthorized use of state equipment is illegal. If such use is detected, it must be immediately reported to the appropriate agency (read "state police"). The state police tend to cooperate with the FBI, Interpol, etc. There is nothing on the departmental level that can be done about it.

Computer system security is a community effort. If you disagree, read the previous few paragraphs again. As a computer user, there are a number of things you can do to ensure that bad things don't happen:


Techniques the Bad Guys Use

In this section, we'll describe some techniques the bad guys use to gain unauthorized access to computer accounts.

First some terminology. People who gain unauthorized access to computer systems for any reason are called "criminals", not "hackers". Hackers are people who enjoy goofing around with computers because it brings them enjoyment. For mathematicians, it is mathematics -- for hackers, it is computers. A criminal may also be a hacker, but the converse is not necessarily true.

At any rate, the criminals employ a number of techniques to break into computers.

One common method is to exploit operating system or application bugs to gain unauthorized access. One good thing about UNIX is that these types of problems tend to get fixed very quickly, often within 48 hours of their discovery. There is a large network of people dedicated to informing network administrators of problems, impacts, workarounds, and fixes for these types of things.

A particularly sinister (but beautifully simple and effective) technique that has been employed is for a would-be intruder to simply call people up on the phone and say something like:

Hi, I'm the sysadmin/grand-poobah. There is a problem with your account over here at X. In order to straighten it out, I'll need to know your password...

[Victim complies].

Thank you... <G R I N>

The Math Department computing staff will NEVER ask you for your password. The reasons are simple: first, we do not want to be responsible for your password. Second, there is no aspect of system maintenance, administration, or operation that requires knowledge of any regular user's password. In fact, there is no legitimate reason for anyone to ask you for your password on any UNIX system.

Another popular method of obtaining username-password pairs is called "network sniffing" or "packet sniffing". This technique exploits a weakness in protocols built on top of TCP/IP.

When you use the telnet, rlogin, or ftp protocols, you are prompted for your username and password on the remote system. Both of these items are sent across the network to the remote system as-is (i.e., without encryption). Packet sniffing works like this: the criminal plugs a computer into the network and simply monitors all traffic that goes by. Any time the string "login:" or "password:" goes by, the machine waits for the response (that you will invariably type) and dumps it into a file. On a busy network, a few hours of this activity will yield a large number of accounts.

Now you may say that the telnet, rlogin, and ftp protocols are stupid. And you'd be right. The people in charge of developing the next generation of Internet protocols are actively working on these and other problems with the current TCP/IP implementation.

There are other schemes like S/KEY and SSH that try to fix this problem. There are other network problems (see below) that S/KEY does not fix (though it nicely neutralizes the sniffer). SSH solves a number of problems and would appear to be an ideal solution. Unfortunately, SSH is not completely debugged yet. In fact, major security holes (due to bugs in the program) were recently found in SSH. Another problem with S/KEY and SSH is that it doesn't do you any good unless both endpoints of the connection are configured for it. This simply isn't the case at the present time.

A fourth method of getting username-password pairs uses so-called "DNS spoofing". When you log in to a machine, it authenticates you by requiring you to type in a valid username and password. You may not have noticed it, but you are not offered the opportunity to authenticate the machine. If you go sit in a computer lab, odds are very good that the machine that says "obsidian.math.arizona.edu" on its screen really is "obsidian.math.arizona.edu".

However, if you go to France and type "telnet obsidian.math.arizona.edu", how do you know that you've really gone to "obsidian.math.arizona.edu"? The answer is: you don't because the login authentication is not mutual. There is an attack in which the criminal temporarily confuses the DNS hostname to IP address mapping in such a way as to route your telnet session to an IP address of the criminal's choice. Then you type in your username and password. And then...

The moral of the story is: Guard Your Password Carefully.

The last method we'll discuss is called "password cracking" or "password guessing". It will be described in the remainder of this document.


Password Guessing

On most UNIX systems, the file containing the encrypted passwords is readable by all users. This means that a would-be intruder can mount an offline attack of all users on the system. Once the criminal grabs the password file, he/she has an exhaustive list of usernames and encrypted passwords for that machine. The criminal simply starts encrypting all possible passwords until a ciphertext match is found. Each match "liberates" a username/password pair.

How hard is this in general? Well, suppose that the criminal knows beforehand that all passwords are only made up of upper and lowercase letters and digits. Further assume this person has a single 200 MHz Pentium Pro at his/her disposal. UNIX passwords (on most systems) can be at most 8 characters long. Here are some worst case timings to guess a single password by brute force:

Password
Length
Possible
Passwords
Crack
Time
4 1.4e7 22 minutes
5 9.1e8 23 hours
6 5.6e10 60 days
7 3.5e12 10 years
8 2.1e14 629 years

If the person has N machines to work with, divide the crack time by N; eg, if you have a password of length 7, it will take the criminal at most 5.2 weeks to crack your password using 100 PPro 200's. Given that most people don't have access to 100 machines, a seven or eight character password seems pretty safe. Anything under 7 characters is clearly quite unsafe.

If you have an 8 character password drawn from the 95 printable ASCII characters (upper and lowercase letters, digits, and punctuation), it could take the criminal up to 19,000 years to guess your password by brute force (on average, it will take 9,500 years per user whose password you want to guess).

Clearly the brute-force method is extremely CPU intensive -- so much so that it appears to be impractical.

Unfortunately, the criminal's job is usually much easier than than a brute force search of all possible passwords. Most people are unlikely to choose a password like A7x;J6Q$ because it is too hard to remember. Instead, people tend to choose passwords that are somehow meaningful to them. It is often the case that users base their password on permutations or substitutions of real words (in some language). The set of "real words" is much smaller than the set of 8 character strings.

Simply guarding your password is not enough. Your password must also be "good". A "good" password is one that is not easily guessed. For example, the following passwords are awful choices for someone named "Mark Hays":

because they are the most obvious choices -- any criminal worth his/her salt would almost certainly try such passwords first. In fact, it is an empirical fact that 4% of users choose passwords based on their username and/or full name.

This fact suggests another approach to password guessing. Instead of targeting individual accounts and trying every possible password, we could instead try a bunch of permutations of login information and liberate 4% of the accounts. We won't know which accounts we'll get; we'll only count on getting 4% of them.

The "statistical" approach is much easier for the criminal. Getting any particular account can take a very long time (many years) but getting a random 4% of them can happen very quickly (a few hours). Most of the time, the criminals don't care which accounts they get, as long as they get at least one (or as many as possible). Any accounts obtained in this manner can be used for whatever nefarious purposes the criminal desires.

This method is so successful that a number of freely available packages have been written to implement it. Perhaps the most popular package is called "crack" (this is the source of the term "password cracking", by the way).

Here's how crack works: first it uses the contents of the password file to build a list of "words" based on permutations of users' login information. It encrypts each of these words and compares the result to the encrypted passwords in the password file. As stated earlier, this generally yields 4% of the accounts.

Having eliminated the easiest guesses, crack makes a series of passes over a set of dictionaries. A dictionary, as far as crack is concerned, is simply a text file containing a list of words, one per line. There are dictionaries of english words, words from TV, German words, French words, etc. available on the Internet. Basically, you can get lists of words in most any language or on most any subject.

One of crack's passes is to simply encrypt each dictionary word and look for hits. This generally liberates an additional 5% of the passwords. This pass takes longer than the login-info pass, but not too much longer.

Subsequent passes of crack transform each dictionary according to a (user definable) set of mangling rules. These rules perform simple permutations and substitutions on the dictionaries, such as:

As distributed, crack performs over 450 such manglings of each word in each dictionary. Statistically, the "liberation rate" is very "good": you end up guessing about 15% of the passwords on your average system in a couple of weeks' time.


Shadow Password Files

On some systems, the regular passwd does not contain the encrypted password information; instead, this data is kept in another file, usually called "shadow", that is not readable by ordinary users. This would appear to render crack useless.

Not so.

The fact is, many people use the same password on multiple computer systems. Since most systems do not use shadow passwords, running crack against the non-shadow system's passwd file will also yield the account on the "more secure" shadow password system. In other words, unless all computer systems use shadow password files, you don't really gain any security. Even if everybody did use shadow password files, a cruddy user password is still a cruddy password. If you pick a random user, telnet to the machine, and try permutations of login data, there is about a 4% chance you'll eventually succeed.

In summary, you really do need to choose a good password.


Math Department Specifics

At the math department, users can choose any password they like. We do not use shadow password files, because, as we've seen, they don't really gain you anything. Given that a percentage of people will choose easily guessed passwords, combined with the fact that any knucklehead on the Internet can install and run crack, the department only has one choice: we must run crack on our own password files.

The reasoning is as follows: if we can run crack and not get any username-password pairs, the casual criminal won't be able to get anywhere, either (because we use larger dictionaries than those distributed with crack). The determined criminal will either have to obtain larger dictionaries or write custom mangling rules (or both) to get anywhere. In other words, by running crack ourselves, we make it very difficult for anyone else to crack departmental passwords.


Choosing a Good Password

Here are some tips for choosing a good password: Here are some things to avoid:


Changing Your Password

Changing your password in the math department is simple. If you want to change the password on your Sun account, log in on one of the Sun consoles (do not go into X windows) and type "yppasswd". You will be prompted for your old password, which you should type in. You will then be prompted to enter and confirm your new password. If you want to change the password for your Linux account, use the command "passwd" instead of "yppasswd". If you have a Sun and a Linux account, you'll need to change your password in both places because the Sun and Linux systems are distinct.

You should not change your password from across the Internet: your new password will be sent in plaintext and will be vulnerable to packet sniffers. Instead, you should sit at the console of a UNIX machine. It's OK to change your math or u-dot password from other UA machines (i.e., from across the campus network).