Authentication and Security

Central to the idea of protection systems is the idea of an authentication system. An authentication system proves the identities of elements with which a computer system interacts. This can include users and other systems.

In distributed systems, authentication should be 2-way: The user should authenticate to the machine, and the machine to the user.

Generally authentication is accomplished by means of the exchange of a shared secret. The most common shared secret is a password.

Passwords

A password is a string of characters that the user and computer system agree will establish the user's identity to the system. The analogy is to physical passwords, where people who wanted access to a military facility had to recite such an unusual phrase to establish their identity to those inside the fort.

Computer passwords are often the weakest part of a computer security system, especially if the passwords can be guessed off-line - that is without alerting the system under attack that it is under attack. Passwords can be stolen (physically or electronically) or guessed.

There are several good rules for choosing a computer password:

• Choose a long one. Most systems allow eight or ten letters - use 'em all. There are only 140,608 3-letter (cap and lower case) passwords; there are more than 50 trillion 8-letter combinations. Guessing 1 in 50 trillion is a literally half a billion times harder than 1 in 140,000.
• Don't use a common phrase or name. A seminal work in computer security ran a cracking program on a couple hundred donated password files that tested common English words and the top 100 (or so) female names and had an ungodly (better than 50%) hit rate. Hopefully education has gotten better. Note that "common phrase" means anything available in the system dictionary, at least. In my opinion you're better off not using any English, and non-English words fare little better. No science fiction or fantasy words, either.
• Include some non-letters, e.g., *&$^@. See above.
• Don't write it down. You've changed a difficult puzzle into a physical search.
• Don't get too attached to it; you should change them relatively frequently - every six months or so is a good idea.

Password Storage

It's possible to store passwords in the open, without immediately giving away the contents of the password. The system uses a 1-way function. A 1-way function is an interesting function that is relatively easy to compute, but difficult to invert (essentially the only way to invert it is to compute all the forward transforms looking for one that matches the reverse).

Systems like UNIX(R) don't store the password, but the result of a 1-way function on the password. To check a user's password, the system takes the password as input, computes the 1-way function on it, and compares it with the result in the password file. If they match, the password was (with high probability) correct. Note that even knowing the algorithm and the encrypted password, it's still impossible to easily invert the function.

Although it's theoretically reasonable to leave a hashed password file in the open, it is rarely done anymore. There are a couple reasons:

• In practice, bad passwords are not uncommon enough, so rather than having to try all the passwords (or half the passwords on average), trying a large dictionary of common passwords is often enough to break into an account on the system.
• Password file can be attacked off-line, with the system under attack completely unaware that it is under attack. By forcing the attacker to actually try passwords on the system that they're invading, the system can detect an attack.

Other Shared Secrets

Some other forms of shared secrets include:

• Shared Real Secrets - the user gives the system some information that "only the user knows" and the system quizzes the user on it instead of a password. Good, in that the user rarely has to write such information down. Bad in that there isn't much information that can't be found by a determined investigator.
• Code books - a frequent system is to ask the user for a word from a code book. This was in vogue for a while with anti-piracy systems; to gain access to a program the program would ask the user for the nth word on the m-th page of the manual. It practice it means that the pirate photocopied the manual.
• One time passwords - the computer generates a table of passwords for the user, each of which is to be used once. When the user tries to log in the computer asks him/her for the next password in the sequence. The advantage is that if an attacker manages to steal the password, it cannot be reused. The disadvantage is that an attacker can steal the list (and a user is unlikely to memorize a set of single use passwords).
• Challenge/Response - The system and user agree on some (one-way) function or transformation. At login time, the computer presents the user with a value (called the challenge) and the user responds with the transform of the value. For example if the function were the square root, a challenge of 9 would be correctly answered with a response of 3. In practice, the functions are more complex and usually encoded in hardware. The hardware is often password protected so that theft of the hardware only means that the user cannot log in, not that the intruder can.

Physical ID

Another shared secret can be physical attributes of the human who wants to access the system. Several body measurements identify a user with significant precision: finger lengths, retina, fingerprints, etc. Controlling access based on physical features has problems if the features are damaged (cutting one's fingertip should confuse a fingerprint scanner). It also raises the grisly possibility of theft of those features. One way to beat a thumbprint scanner is to physically acquire someone's thumb.

A Sampling of Attacks

Some common attacks on computer systems:

• Trojan Horse - This is a benign program that steals information as part of its function. An example is a script that mimics the login prompt, takes a user's password, saves it for the owner of the script and logs the user in. The legitimate user has access to the account, but so does the owner of the script.
• Password Guessing - we talked about this with passwords. I pause to mention the infamous TENEX security hole that Tannenbaum discusses. TENEX allowed user functions to be called on each page fault. Some clever user realized that this allowed password guessing by the letter instead of one letter at a time. The password being guessed had one. letter on one page and the rest on another, which was forced out of memory. Passwords were checked letter-by-letter, sequentially. If the first letter was correct, there would be a page fault when the system faulted the second into memory to check it. By repeating the process the whole password could be guessed sequentially. This is an interesting example of how multiple OS feature combine to affect security.
• Social Engineering - This is by far the most difficult to control. An attacker simply lies to a human being and gets the information that they want. The only real cure for this is to educate anyone who has security information (that is everyone) about security.
• Buffer overruns - forcing a program to overrun a variable on the stack and insert code in it that the attacker wants run.
• Backdoors - sometimes developers leave privileged debugging hooks in place in production systems. One of the well known offenders here is sendmail. Other production systems used to ship with well known user names with well-known passwords for remote maintenance. (Microsoft actually does this.)

Viruses and Worms

Viruses are programs contained in other programs, often for malicious purposes. (They needn't be, though - one can imagine benign programs propagated the same way - virus checkers for example). Worms are self replicating independent programs. The distinction is in the method of transmission: a virus needs a host program to be run to propagate it; a worm has no such host, it propagates itself. Both have made national news for in their malevolent forms, but both could be used for benign purposes.

Covert Channels

A covert channel is an unintentional communication channel in the system. For example, if 2 processes banned from communicating directly can use the following scheme: one process repeatedly performs a computation known to take a fixed time. The other process alternately loads and unloads them machine with computationally intensive child processes depending on the bit it wants to send. Loading the machine corresponds to a 1 and unloading the machine a 0. The listening process knows that if it's computation takes longer than usual, it should record a 1 and if it's shorter, record a 0. The two can work out the timing and loading (statistically, if necessary) to communicate.

Covert channels are necessarily low bandwidth, and stopping them is difficult. (In the example above, the system would have to guarantee system load to be fixed, which would mean slowing the system when it was unloaded.) Most systems don't stop covert channels. Systems that hold serious enough data, do.

Conclusions

Security is a design concern for most, if not all systems. It requires an attention to detail, and a somewhat devious mind to design an effective system.