June 2002
Abstract
This paper describes the various user authentication mechanisms available in FreeBSD 5.0. We start with an overview of traditional Unix authentication, then go on to describe historical attempts to remedy its weaknesses. Next, we look at how the Pluggable Authentication Module framework integrates these mechanisms and facilitates their deployment. Finally, we take a tour of commercial hardware-based authentication systems and describe how they can be integrated with FreeBSD to provide more secure authentication, both locally and across a network.
Table of Contents
YTBW
AT&T is a trademark or registered trademark of AT&T, Inc.
S/Key is a trademark of Bell Communications Research, Inc. (Bellcore.)
Sun, Sun Microsystems and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc.
Unix and The Open Group are trademarks or registered trademarks of The Open Group.
Windows is a registered trademark of Microsoft Corporation.
The traditional Unix authentication mechanism, which appeared in Version 6 AT&T Unix, is based on a file (usually /etc/passwd) listing users and their passwords. Since this file is usually world-readable, the passwords are encrypted; when a user logs in, the password she types is similarly encoded, and the result is compared to the hash listed in /etc/passwd. The use of a one-way hash function ensures that the actual passwords cannot be recovered from the password file, except by brute force.
The most common hash function is based on DES. It consists of doing 25 encryption rounds with a fixed key, using a 24-bit ‘salt’, which is usually generated by a PRNG, to render the algorithm irreversible. The salt is usually generated randomly for each password, and is included in the output of the hash function so it can be used to hash the password typed in by the user at logon time.
The traditional DES-based hash only hashes the first eight octets of its input, making brute-force attacks on a leaked password list feasible on modern hardware. For that reason, FreeBSD only supports it for backward compatibility and interoperability with other operating systems. For day-to-day use, FreeBSD prefers a hash function developed by Poul-Henning Kamp, based on MD5. It supports passwords of arbitrary length, and is far slower to compute, making brute-force attacks far more difficult.
FreeBSD also supports yet another hash function designed by David Mazieres and based on the Blowfish cipher. It can handle passwords of arbitrary length, like the MD5-based hash, but also an arbitrary number (up to 231) of encryption rounds, allowing the admin to select a suitable compromise between convenience (a slow logon annoys users) and security (slow hashing makes brute-force attacks more difficult), and to update this figure over time, as processor speeds increase.
Most other Unix-like operating systems only support the DES-based algorithm, while NetBSD and OpenBSD support the same algorithms as FreeBSD, and at some Linux distributions have recently started to use an MD5-based hash.
To further reduce the chances of success of a brute-force attack, many operating systems (including Solaris and most Linux distributions) support the use of a ‘shadow’ password file (usually /etc/shadow), which contains the real (hashed) passwords, and is readable only by the superuser. When shadow passwords are in use, the regular password file (which still needs to be world-readable) contains dummy passwords which will never match the output of the hash function.
FreeBSD, and other operating systems based on 4.4BSD, make exclusive use of shadow passwords. There is no way for the admin to decide not to use them, short of rewriting parts of the system libraries.
This is the baseline; every other authentication mechanism discussed in this paper is an attempt to supplement or replace this one. Its only notable strengths are its ubiquity simplicity.
The fundamental weakness of the traditional Unix authentication mechanism is the fact that it is based on static passwords. Good passwords are difficult to remember, and users tend to write passwords down for fear of forgetting them, which means they can be discovered by third parties. Passwords can be snooped through ‘shoulder-surfing’, or captured by trojaned software or hardware. Changing passwords often decreases the window of risk if they should fall into the wrong hands, but makes them even harder to remember. Care must be taken to avoid transmitting them over insecure channels, or typing them on untrusted machines (such as those found in terminal rooms at conferences.) Educating users about these dangers can be a daunting task.
In addition, systems that need to share their password files with machines running other operating systems are in most cases compelled to use the DES-based hash function, which can only handle passwords of up to eight characters, and is quite fast to compute, both of which make brute-force attacks far easier than with other hash functions.
OPIE (an acronym for ‘One-time Passwords In Everything’) is a software-based dynamic key generation system, inspired by and backward-compatible with Bellcore's S/Key. At its heart, OPIE is an iterative algorithm for generating a sequence of 64-bit keys. The starting point for the sequence is a passphrase of arbitrary length selected by the user. Each successive key is generated by combining the previous key with a seed which is generated randomly when the sequence is initialized.
When the user wishes to log in, the system prompts her with a sequence number and the seed for the current sequence. The user then provides the sequence number, the seed, and her passphrase to a program which computes the appropriate key for this session. Once the user has successfully logged in, the key is ‘consumed’, and the next time she logs in, she will be asked for the next key in the sequence.
Since the sequence depends only on the passphrase and seed, it is possible to compute keys in advance and print them out for when no password calculator is available.
OPIE is enabled by default in FreeBSD 5.0. All a user has to do to start using it is run the opiepasswd(1) program to initialize her key sequence. The next time she tries to log in through a channel that supports challenge/response authentication, she will be presented with an OPIE challenge. The opiekey(1) program can be used to compute responses and generate password sheets.
Note that by default, users for whom an OPIE sequence exists are not allowed to log in with their Unix password. This is controlled by the /etc/opieaccess configuration file.
Since each password is used only once, OPIE is not vulnerable to replay attacks or traditional password capture attacks. It can therefore safely be used to authenticate users communicating over insecure channels, or from untrusted hosts.
There is no way for the password calculator to determine the correctness of the passphrase; no matter what the user types, the calculator will spit out a seemingly valid 64-bit key. The only way to determine its correctness is to attempt to log in with it.
It is possible to generate a number of passwords in advance and print them out or write them down, thus avoiding the need to type one's passphrase on an untrusted system.
The user is dependent on a trusted device on which to compute passwords, although this can easily be a PDA, a cell phone, or some other portable device. Of course, if the user is seated at a trusted workstation, she can run the password calculator on that workstation.
Shoulder-surfing is still a problem when typing in the passphrase. The alternative, pre-printed password sheets, is also imperfect as the sheets can be stolen, though this is a risk users understand and are used to handling—at least those that routinely carry credit cards or a driver's license in their wallet.
Kerberos was developed as part of MIT's Athena project, to solve the problem of reliably authenticating users across untrusted networks and providing single sign-on semantics.
Kerberos relies on a trusted third party (the Kerberos domain controller, or KDC) to authenticate principals, which are users or services. If authentication is successful, the KDC issues the requesting principal a time-limited ticket and a session key which it can use to communicate with the target principal. Kerberos thus embodies two different authentication mechanisms: primary authentication, in which a principal uses a password to obtain a ticket from the KDC, and secondary authentication, in which a principal uses the ticket to authenticate itself to another principal.
FreeBSD includes both MIT Keberos IV and Heimdal, which is a free implementation of Kerberos V developed at KTH (the Swedish Royal Institute of Technology.) They are not installed by default, but can be selected at install time or enabled in /etc/make.conf prior to a build. Most of the Kerberos V tools have been renamed to avoid name collisions when both Kerberos IV and V are enabled; for instance, the Kerberos V version of kinit(1) is called k5init(1).
Provided Kerberos is enabled, all it takes for a user to start running it is to set her Kerberos password with the kinit(1) (or k5init(1)) command.
Kerberos is fairly widespread and well understood. It can serve equally well as a centralized authentication system (more on that later) or on a single system, and provides single sign-on semantics as well.
When used to authenticate users on a single system, Kerberos does little more than traditional Unix authentication, except in cases where single sign-on is an important issue. It is also fairly hard to administrate properly. Its true value only becomes apparent when it is used to provide centralized authentication for a larger number of machines.
Centralized authentication systems address the problem of maintaining a uniform authentication database across multiple systems.
A common theme to all the systems listed below is that—unless the server crashes—the user will normally not be aware of their use; they work entirely behind the scenes, and the user will not know that the system she is logging in on obtained her authentication data from a server rather than a local file.
NIS (also known as YP, though that name has been abandoned for trademark reasons) is a mechanism for distributing system configuration files across a network. NIS supports indexed ‘maps’ that map keys (such as a user name) to records (such as a Unix password entry).
NIS is widely supported, well understood, and relatively easy to set up (though it can be difficult to debug, especially for a novice, if something goes wrong.) It greatly simplifies the distribution of site-wide configuration files.
Provided rpc.yppasswdd(8) is running on the server, NIS allows users to change their password using the traditional passwd(1) command.
NIS is a distribution system rather than an interrogation system. For that reason, it is not suitable for use with other authentication mechanisms than traditional Unix passwords. Although one could envision using NIS to distribute, say, OPIE state files, there is no way for clients machines to notify the server when a key is consumed and the state file should be updated.
In addition, NIS traffic is not encrypted, and the server has no way of identifying a client, so any user (or anyone able to sniff network traffic) can obtain any other user's hashed password and attempt a brute-force attack. NIS support for shadow passwords is ad-hoc at best; although FreeBSD supports separate distribution of the shadow password file and a imposes certain amount of restrictions on who can access it, neither Linux nor Solaris do.
When deploying NIS in an open environment, one is pretty much restricted to the lowest common denominator—DES passwords and no shadow file.
Although Kerberos has already been described, it is worth mentioning here because it also supports centralization of authentication data, and is one of the oldest such systems still in use.
Kerberos is open and fairly old and therefore available on practically every operating system. Microsoft recently adopted Kerberos V as the underlying authentication mechanism for their Windows 2000 operating system; although their implementation has a number of quirks and bugs, it is possible to combine FreeBSD hosts (running Heimdal) with a Windows 2000 KDC and vice versa.
Kerberos uses public-key cryptography to sign and encrypt tickets and is therefore far more secure than any of the systems listed above. Tickets are also timestamped and time-limited, making replay attacks difficult as long as all systems in the realm have fairly accurate clocks.
Kerberos also provides single sign-on semantics in that as long as a user holds a valid ticket, she can use it to log in on another machine in the same realm—even recursively.
Data Encryption Standard
Kerberos Domain Controller
Network Information Service
‘One-time Passwords In Everything’, a reimplementation of S/Key.
See Also S/Key.
One-Time Password
Pluggable Authentication Modules
Personal Digital Assistant
Pseudo-random number generator
A challenge / response system based on generating a keystream from a user-provided passphrase.
A random factor which is introduced into a symmetric encryption algorithm to make it irreversible.