Almost everyone uses them, many people have lots of them, they control access to our most valuable asset—information—and yet we don't guard them properly. We share them with others, we write them on bits of paper, and we rarely bother to select good ones. What am I talking about? Passwords, of course (or more accurately, a set of credentials consisting of a username and password).
Usernames and passwords have been used to control access to computers and networks, and the data stored on them, for decades. The problems associated with usernames and passwords are well known, and yet no amount of technology, awareness, or education seems to matter. They remain one of our biggest security vulnerabilities, yet businesses continue to use them. It's almost impossible to make an online purchase without first creating or logging on to an account. I personally have more than 30 accounts, ranging from my online banking and investment accounts, to shopping sites, to professional associations. These are in addition to the accounts (both end-user and administrator-level) that I use to access the various computers and networks required to perform my job.
How does one keep track of so many sets of credentials? The obvious answer is to use the same set of credentials for each account. This practice is risky because if an attacker discovers the set of credentials you use to access one account or system, then he or she has access to all your other accounts. Another option is to store your credentials somewhere (e.g., on a piece of paper in your wallet or on a device such as your smart phone or Pocket PC). This approach also has risks. If your wallet is stolen or your device is compromised, then all your accounts are compromised. Even if you store your password separate from your username, you might still be at risk if only the password is compromised, as often usernames are easily guessable. For example, many Web sites force you to use your email address as your username. (For more information about best practices for situations in which you must use passwords, see the sidebar "When You Must Use Passwords")
So, what can a security administrator do to avoid the risks associated with passwords? A bewildering array of alternatives to the use of usernames and passwords exists— some supported natively by Windows and some not. Three of the most popular alternatives are smart cards, tokens, and biometric readers. After a brief look at some basic authentication principles, I'll discuss the pros and cons of each solution and the scenarios in which they work best.
The Basics of Authentication
Current authentication technology uses three types of identifiers: something
you know; something you have; or something you are. When a system uses just
one of these identifiers, it's known as one-factor authentication. An example
of one-factor authentication is the humble username and password, which is based
on something you know. When an authentication system uses two of these methods,
it's called two-factor authentication and is considered more secure than one-factor
authentication. An example of two-factor authentication occurs when you use
your ATM or debit card and PIN, which requires something you know and something
you have. Figure 1 shows an excerpt from the
June Windows IT Pro "Two-Factor Authentication Tokens" Buyer's Guide
table, which lists some two-factor authentication products that are currently
available. To learn more about two-factor authentication and to view the complete
Buyer's Guide table, read "Two-Factor Authentication Tokens" InstantDoc ID 49938.
Some banks recommend that you have your photograph added to your ATM or debit card. This is an example of three-factor authentication, which is more secure yet. A sales clerk checks the card's photograph for a match with the person presenting the card before inserting it into the point-of-sale (POS) terminal and asking the person to enter his or her PIN.
Consider the example of your ATM or debit card and PIN. You need both the card and PIN to withdraw cash or make a POS purchase. A stolen ATM or debit card is essentially worthless without the PIN, which is why your bank recommends that you never write it down or tell it to anyone. Because most PINs are only four digits in length giving a maximum of 10,000 possible combinations, a user must enter the correct PIN within a specified number of attempts, usually three, before the account associated with the card is locked out. Without such a threshold, an attacker with a stolen card could leisurely attempt each possible PIN to gain access to the account. Some card issuers have introduced the concept of a duress PIN. A duress PIN is an alternative PIN that, when used, tells the card issuer that the account owner was forced to give up his or her card and/or PIN, and to make it look like a transaction (e.g., a funds transfer) is working or to report that there are insufficient funds for the transaction to complete, while the appropriate authorities are notified and dispatched.
It's important to note that successfully authenticating yourself to a system doesn't give you unrestricted access. For example, before you can access your bank account or files on a server, you must be authorized. Authorization is governed by limitations such as sufficient funds or permissions in a discretionary ACL (DACL).
Smart Cards and Certificate-Based Tokens
Smart cards, such as those from Gemplus (http://www.gemplus.com/smart/cards/basics), and certificate-based tokens, such as SafeNet's iKey
series (http://www.safenet-inc.com/products/tokens),
are examples of two-factor authentication technologies. They have much in common.
Both contain microprocessors that support cryptographic operations such as the
generation of keys and hash functions. Each also contains a small amount of
memory, usually between 8K and 32K, to store one or more X.509v3 digital certificates
and associated private keys. The primary difference between smart cards and
certificate-based tokens is that a smart card requires an attached or built-in
reader on each laptop or workstation, whereas a certificate-based token usually
has a USB interface and requires only an open USB port, which most laptops and
workstations already have. Windows ships with the necessary drivers for using
smart cards and certificate-based tokens with many popular devices.
Before a user can use a smart card or certificate-based token to authenticate to Windows, the user must have a certificate issued to the device. An enrollment agent—typically an administrator or other privileged user who has the ability to create and associate certificates to user accounts—inserts the smart card into a reader or the certificate-based token into a USB port on an enrollment station before launching the enrollment application. The enrollment station usually is a secured computer with the necessary hardware and software required by the smart card. The enrollment application might be a standalone tool or something as simple as a Web browser pointed to the Certificate Services enrollment Web site (http://<CAwebserver>/certsrv). This authentication scheme requires a Public Key Infrastructure (PKI) integrated with Active Directory (AD). The good news is that Windows 2003 and Win2K ships with a Certification Authority (CA) and the necessary enrollment components.
When the enrollment agent enrolls a user to use a smart card or certificate-based token, a public/private key pair is generated on the smart card or certificate-based token device and the public key is sent to the CA. The CA creates and signs a certificate and returns a copy to the enrollment station, where it's written to the authentication device. A copy of the certificate is also stored in AD as an attribute of the user to whom it was issued. During the enrollment process, the enrollment agent is asked to enter a user PIN, which is used to restrict use of the private key on the device. The enrollment agent might also set an administrator PIN. The user PIN can be entered only a specified number of times, usually three, before the card becomes locked. Once locked, the administrator must use the administrator PIN to unlock the card and enter a new user PIN. If a smart card or certificate-based token is lost or stolen, the certificate stored on it can be revoked, making the device useless for authentication purposes even if the PIN is known or guessed.
A user logs on to a machine by inserting the smart card into a reader or plugging in the certificate-based token to a USB port. This action replaces the Ctrl+Alt+Del sequence and prompts the user for a PIN rather than a username and password. The PIN is used to unlock the device, specifically to permit the use of the private key in cryptographic operations. The private key never actually leaves the device. The user's certificate is read from the device and sent to a domain controller (DC) as part of a Kerberos logon sequence. The certificate is validated to ensure that it was issued by the AD-integrated PKI, hasn't expired, and hasn't been revoked. If the certificate is valid, the public key contained in it is used to encrypt a logon session key, which is returned to the user's workstation and sent to the smart card or certificate-based token device for decryption by the private key. If decryption is successful, the standard Kerberos logon sequence continues. You can read more details about Kerberos logons with Windows in the article "Windows 2000 Kerberos Authentication" http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/kerberos.mspx.
You can also use smart cards and certificate-based tokens to authenticate to Web sites and applications. In the case of authenticating to a Web site, the mechanism used is typically Secure Sockets Layer (SSL)/Transport Layer Security (TLS), and the certificate is used to authenticate the user. If you use Microsoft IIS, you can configure Web sites to require SSL/TLS instead of anonymous, basic, or integrated (NT LAN Manager—NTLM) authentication. When you use SSL/TLS, you can easily add an extra layer of security so that if a user accidentally remains logged on, an attacker can't browse a sensitive Web site without access to the smart card or certificate-based token and the correct PIN. It's also possible to map certificates to specific user accounts in IIS. This option can be very useful if your organization has Web servers in an extranet forest, you require customers and partners to authenticate to your servers, and you know that they use smart cards or certificate-based tokens. Although you didn't issue the certificates, you can choose to trust them and map them to user accounts in your extranet forest.
Although not as secure as using smart cards or certificate-based tokens, it's possible to issue a X.509v3 certificate to a user for authenticating to a Web server and have it stored in his or her Windows profile. The Data Protection API (DPAPI), which protects keys such as a certificate's private key, can be configured to require users to enter a PIN each time they want to access their private key. This is still an example of two-factor authentication. You can request certificates and private keys for your users and partners, then encrypt them and send them via email. You can then provide the symmetric key necessary to unlock and install the certificate and private key out-of-band or via S/MIME-encrypted email.
One advantage of using smart cards and certificate-based tokens is that the certificates issued and stored on them can be used for more than just authenticating to Windows and accessing Web servers. You can use the certificates to encrypt or digitally sign email messages and documents and for VPN access to Windows RRAS. Another benefit of using these devices to log on to a workstation is that because they rely on a certificate's key pair, they mitigate the risk of userselected weak passwords being cracked by people eavesdropping on Kerberos traffic between the workstation and a DC.
Token-Based Systems
Certificate-based tokens aren't the only form of token used to secure authentication. Perhaps the most widely used token-based authentication system is RSA Security's SecurID. RSA Security has several versions available ranging from rack-mountable server devices to a software version, called RSA SecurID for Microsoft Windows, which is specifically designed for use in Windows environments (http://www.rsasecurity.com/node.asp?id=1173).
Token-based authentication systems are two-factor authentication systems. The form factor of a token is usually either a credit card?sized device that can go into a wallet or a key fob-sized token that can go on a key ring. Each device has a unique serial number and typically an expiration date, after which the token can't be used. The token works by displaying a unique number, usually six digits in length, every 60 seconds. When the token is issued to a user, it under-goes a PIN reset operation in which the token is synchronized with the server software. When authenticating to a workstation, VPN server, or Web server, the user is required to enter a username, optionally a password (depending on the solution), the number displayed on the token at that time, and usually a four-digit PIN issued to the user and which never changes. Users are given a limited number of attempts to enter the current number on the token and the PIN. Repeatedly entering the wrong numbers will cause the user account to be locked. The need to know the user's PIN means a stolen token can't readily be used by an attacker to access a system. An administrator can disassociate a lost or stolen token from a user's account, making it impossible for an attacker to use the token. If the token is recovered, it can be associated with another user's account.
Token-based authentication is very strong and works well in heterogeneous environments. The downside is the need to install authentication server software specific to the token-based authentication solution and the need to deploy client-side authentication software on every user's desktop and laptop. Another disadvantage is the relatively high cost of the tokens, especially considering that the tokens will eventually expire and need to be replaced.
As an alternative to expensive hardware tokens, some vendors, including RSA, offer software-based tokens that run on devices such as Pocket PCs. As with hardware-based tokens, soft-ware-based tokens must be synchronized using a PIN reset operation when associated with a user account.
Biometric Readers
The most common type of biometric reader in use today is the fingerprint reader. More and more laptops are being shipped with built-in fingerprint read-ers, and USB fingerprint readers are readily available. Less common types of readers include the palm reader and a reader that measures the spread of the user's fingers and the pressure exerted against raised posts on the surface of the reader. Iris and voice recognition systems aren't routinely used today except in high-risk environments.
The principle behind biometric readers is simple. The reader measures the biometric being scanned and reduces it to a unique value, usually a hash. For example, a fingerprint reader might calculate the ratio between ridges and troughs on the presented finger and convert that into a hash value. A word of caution is necessary: Less-expensive biometric readers might present more Type I and Type II errors than more expensive readers. A Type I error is a false negative (e.g., a valid fingerprint or other biometric is falsely rejected). A Type II error, which is more worrisome, is a false positive (e.g., an invalid fingerprint or other biometric is wrongly accepted). Because of the fallibility of biometric technology, manufacturers of many biometric readers, including Microsoft with its Fingerprint Reader, recommend that you don't use the devices to control access to corporate networks or sensitive financial information. A biometric reader is inherently a one-factor authentication device, based on the assumption that everyone has unique biometrics. Some biometric authentication systems will require a user to also enter a PIN in an attempt to reduce the number of Type II errors.
If you choose to use biometric readers, you'll also need to deploy the software used to authenticate users. Before a biometric reader can be used, the people who will be authenticating via the reader will need to record their biometrics. Often multiple scans of each biometric are taken, and occasionally multiple biometrics are scanned (e.g., the index finger on the left and right hands). These recorded biometrics are then associated with the user's account. Each time a bio-metric is presented, the reader scans it and compares the resulting unique value against the values associated with user accounts to find the user who presented the biometric.
Biometric readers are best used to minimize the number of credentials that users need to remember, not to eliminate the need for credentials. For example, when a user logs on to a Web site, the biometric authentication system records the credentials used and the action that submits the credentials to the Web site (e.g., clicking a logon button). When the user returns to the Web site, he or she simply presents their biometric to the reader and it will fetch the credentials from a secure store, fill out the Web form, and simulate the action necessary to submit the credentials to the Web site and log on the user.
Federated Authentication Systems, SSO Solutions, and InfoCards
Although not replacements for credentials, federated authentication systems and single sign-on (SSO) solutions provide a way to reduce the number of credentials a user must manage. A federated authentication system is one in which Web services that a user accesses contact a directory or authentication server in the user's domain or forest (or equivalent) to obtain an authentication token that can be used to identify the user. The token is either mapped to a user account on the target system or is trusted in its own right by the application running on the target system. You can read more details about Microsoft's implementation of federated authentication, Active Directory Federated Services (ADFS), at http://www.microsoft.com/WindowsServer2003/R2/Identity_Management/ADFSwhitepaper.mspx.
An example of a Web-based SSO solution is the Microsoft Passport system (http://www.passport.com). Although predominantly used by Microsoft, there's no reason why an enterprise can't use Passport to permit users to authenticate themselves to that enter-prise's Web sites. There's even support for Passport in Windows Server 2003 and Microsoft Internet Information Services (IIS) 6.0. For more details about how to use Passport with your Web sites, visit http://technet2.micro soft.com/WindowsServer/en/Library /3 4 1 5 3 b 8 f -c 4 b a -4 8 b 0 -8 2 e 4 -7e0a568aacd71033.mspx, where you'll find step-by-step instructions and links to additional resources. Note that before you can deploy a Passport-enabled Web-application, you need to register with Microsoft and pay a fee. Microsoft has committed to ensuring interoperability between the Passport service and the solutions developed by the Liberty Alliance Project, a consortium dedicated to developing specifications that define federated identity management protocols (http://www.projectliberty.org).
Perhaps the most exciting development on the horizon that will address the problem of managing multiple sets of credentials is Micro-soft's new InfoCard technology. Despite its name, InfoCard isn't a hardware device; it's a means to manage multiple identities in a consistent manner and is integrated into the user's Windows profile. You can find more information about InfoCard at http://msdn.microsoft.com/windowsvista/building/infocard.
The Password Dilemma
Managing access to networks and Web sites is a problem that every IT pro faces. Because of the problems associated with authentication methods that use a username and password, many companies are moving away from using them. I've given you some common and easy-to-use alternatives to usernames and passwords. In future articles, I'll delve into the details of how to deploy and use some of the technologies and solutions I've described.
