Beyond Passwords Part 2: Implementing The Vision

By Lisa Phifer | Posted April 15, 2005

In Beyond Passwords: Stronger Authentication, Part 1, we explained the problem and showed why organizations are interested in improving on password authentication. In part two, we examine the solution.

Organizations that want to implement stronger authentication have a dizzying array of alternatives and products to choose from. To get started, let's break the alternatives down into categories and identify a few products in each category.

Digital Certificates
Digital certificates are based on Public Keys, a cryptographic system whereby pairs of keys are generated with a unique mathematical property: anything encrypted by one key can only be decrypted by the other key. In each pair, one key must be safeguarded and known only to the legitimate user — this is the Private Key. The other key is given freely to everyone who wants to authenticate the private key holder — this is the Public Key. If you encrypt a known value with your Private Key, anyone else can decrypt that value with your Public Key and compare those two values. If they match, you are considered authentic because you demonstrated that you hold the Private Key.

For authentication, your identity must be somehow tied to your key pair. This is the purpose of Digital Certificates. A certificate binds a public key to a named entity and some information about that entity (like company, state and country). Although this binding could be supplied to each correspondent out-of-band, that would not scale well or let strangers authenticate each other. To solve this, certificates are issued by Certificate Authorities (CAs): trusted third parties that generate and "sign" certificates using their own private keys. In this way, everyone can know the public keys of a few trusted "root" CAs and accept any certificates generated by those CAs.

Digital certificates form the basis for the SSL server authentication widely used by e-commerce sites. Every Web browser includes a list of well-known root CAs. For example, Internet Explorer's trusted root list includes Thawte's certificate (below).

Click to view larger imageOrganizations may purchase certificates from these root operators, or they can install in-house CAs to generate, distribute and revoke their own digital certificates. Managed Security Service Providers (MSSPs) that provide Managed PKI services generally use their own CA(s) to generate certificates for use by their customers.

For example, an MSSP might issue an "intermediate" CA certificate to YourCorp and sign all of YourCorp's user certificates with that CA's private key. YourCorp must then install that trusted CA certificate in every system. When a YourCorp customer wants to authenticate, she presents her certificate, signed by YourCorp's CA and a value (thumbprint) encrypted with her own private key. The recipient uses the CA's public key to verify the certificate is valid. He then extracts the subject name and public key from the certificate to authenticate the user. This process happens transparently in the background as you conduct your e-mail or online business.

Even from this brief description, it's clear that Public Key Infrastructure is a complicated subject. Larger enterprises often have the IT staff and security expertise to deploy a PKI, if they choose to do so. But many SMBs do not — and this is where MSSPs can step in to help fill the gap. To roll your own CA, start with a PKI platform, available from many sources, including:

To learn more about Digital Certificates and deploying a PKI, consult these vendors' Web sites and third-party sites like this PKI Page. Today, digital certificates are widely used for server authentication — for example, site-to-site VPN gateway authentication. They can also provide strong user authentication — for example, in wireless LANs using 802.1X with EAP-TLS.

However, many organizations have been scared off by PKI complexity and cost. To date, most companies have pursued other options for stronger-than-password user authentication.

2. One-Time Passwords
Let's jump to the opposite end of the complexity (and security) spectrum to consider One Time Passwords (OTPs). Password crackers rely on people reusing the same password. Cracking a password that's only good for a single use is of little practical value. OTPs capitalize create an authentication system whereby each password can be presented for authentication just once. After an OTP is used, it can never by used again (or at least not any time soon).

OTP authentication systems rely upon a pre-defined relationship and synchronization between the user and authentication server. A well-known, freely available OTP system is S/KEY, developed by Bellcore in the '90s as the basis for RFC 2289, the IETF OTP standard. The user provides a secret and a number of passwords to generate, and the password generator creates an ordered list of passwords. When the user tries to authenticate, the OTP is sent to the server. If authentic, the server adjusts the user's password counter so that, next time, he'll be prompted for the next OTP on the list and so on.

S/KEY utilities are freely available for virtually every operating system, including:

Click to view larger imageS/KEY's successor, OPIE (One-time Passwords In Everything) is also available from many sources; many links are given in this NASA Website list. Some remote access products include S/KEY authentication as an option. For example, Citrix OnLine's GoToMyPC Corporate OTP generator is shown here (right).

Like "regular" passwords, OTP security depends on the strength (length and randomness) of the original secret (also called a pass-phrase). RFC 2289 advises starting with pass-phrases that are at least 10 characters, and as many as 63. While OTPs are not vulnerable to passive eavesdropping, they can be compromised by active race attacks, where someone listens to a series of OTPs and guesses the remainder, racing the user to complete subsequent authentications. The attacker must have the opportunity to watch the same user log in several times in row to perform this attack, and the system must rely upon OTP as a solo authentication factor.

S/KEY and OPIE can be a rather inexpensive way to improve the security of password-based authentication. Client and server software may be free, and there's no client-side hardware to buy. However, one reason that companies don't use S/KEY and OPIE more often is that they are unwieldy for end users. Finding OTP #35 on a list and typing in a long string of odd characters correctly is harder than typing in a plain old password. Running an OTP utility to re-generate #35, then using cut/paste to copy that hash into a login prompt may reduce typos, but is still awkward.

3.Hardware Tokens
Hardware tokens are the most popular two-factor authentication method in use today. Traditional tokens take the concept behind one-time password generation to a whole new level, combining that with a second authentication factor. Newer hardware tokens tend to pair different kinds of credentials, skipping passwords altogether.

RSA SecurIDAlthough token authenticators are also available as software clients, most are sold as a small piece of hardware — a keychain fob, a credit-card sized PINpad, or a USB device. For example, this figure (right) illustrates a traditional RSA Security SecurID Fob and SecurID PINpad. As we can see, both tokens display a number — this is effectively a one-time password. However, instead of being statically generated with an algorithm like S/KEY, a new pseudo-random number is dynamically-generated every 60 seconds. The next number cannot be predicted or guessed, except by the Authentication Server that initialized the token.

After initialization, whenever the user attempts to authenticate, she is prompted for a "passcode." In response, she types the number currently displayed on the token, followed by her Personal Identification Number (PIN). This interaction is similar to "normal" password authentication, so it fits well with many protocols and applications. If the user reaches the end of a 60-second interval, she may be prompted for another passcode, and of course she cannot authenticate if she's accidentally left her token at home. Replacing a lost token isn't as instantaneous as resetting a forgotten password. However, many organizations consider these to be minor inconveniences in light of the significantly stronger authentication that two-factor hardware tokens offer.

VeriSign Unified USB AuthenticatorsRecently, there has been considerable growth in USB hardware tokens. Some USB tokens can operate in a fashion similar to that just described and support other (non-interactive) forms of strong authentication. For example, the Verisign Unified USB Authenticators illustrated at right are available in two form factors — one that supports token code display and another that does not.

USB hardware token functions vary quite a bit, but generally support more automation and multiple authentication methods, including digital certificates. For example, ActivCard's USB Key stores a user's private keys, passwords and profiles for network access. You plug the key into a USB port on your computer and enters histour PIN. Thereafter, you can be authenticated using any of the credentials stored on the key — legacy password, dynamic one-time password or certificate. USB keys work with client software installed on the user's computer—in this example, ActivCard Gold.

Many vendors sell authentication tokens. Most sell an assortment of hardware, including fobs and USB keys and combinations thereof. Some also sell passcode-generator software to turn a small-footprint device like a PDA or Smartphone into a token. A few examples of vendors in the hardware token market include:

Allocating tokens, replacing damaged or lost tokens, and purchasing the associated authentication server software does involve cost. For example, a 2004 Infrastructure Software and Systems Management survey published by the Susquehanna Financial Group stated that RSA Security's average selling price is about $40 per token with a typical three-to-four year life.

Vendors do compete vigorously on token pricing and offer volume discounts, so consider this merely as one example, and do your own shopping.

4. Smart Cards
With the advent of USB tokens, the division between Smart Cards and tokens has become somewhat fuzzy. But traditional Smart Cards are what you no doubt picture — a plastic card, the same size as most credit cards, with an electronic microchip embedded right into the card. The chip contains information about the cardholder that can be read only by a card reader. Although Smart Cards have many possible uses — for example, as a pseudo-cash card to make point-of-sale payments, or as a badge to enter a secure facility — they can also be used for network authentication. In particular, the microchip can store the cardholder's digital certificate and key pair.

For example, below we show the VASCO Digipass Go2, a card reader that accepts various compatible Smart Cards. Note that some bank credit cards issued today are, in fact, Smart Cards. To use this device, you insert your card and enter a PIN into the reader. Thereafter, you can respond to Digipass Authentication Server prompts until the card is removed from the reader.

VASCO Digipass Go2

Smart Card readers don't have to be standalone devices. The ActivCard PCMCIA Reader (below) is capable of reading the information embedded in the microchip on the adjacent ActivCard Corporate Access Smart Card. If you can insert your Smart Card into a PCMCIA slot, why not use a USB port? And that is, in fact, what many USB Keys are: Smart Cards in a USB form factor.

ActivCard PCMCIA Reader

Form factor matters quite a bit to end users, so you'll want to choose carefully when deciding what kind(s) of hardware credentials to issue with a premium authentication service. Consider where and how your employees work, devices they carry and credential portability (for example, do they need to authenticate from a public PC). From a security perspective, carefully consider which factors any given Smart Card supports, the security of the token/card/reader and associated client/server software, and compatibility with the network services and applications to be accessed.

5. Biometrics
Certificates, OTPs, tokens and smart cards all represent "something you have." Let's briefly consider that third authentication factor: "something you are." Authentication methods that employ this factor are known as biometrics. Biometric authentication samples physical characteristics and uses them to verify the user's claimed identity.

Perhaps the most well known biometric method is fingerprint analysis. Fingerprint authentication captures an image of the user's fingerprint, identifies unique points and patterns and compares them to a biometric template created during an earlier (and known valid) scan of the user's fingerprint.

Silex TechnologiesFor example, Silex Technologies sells several fingerprint sensors, including the Combo-MINI (USB token with fingerprint sensor, MSRP $179) and MUSB200-Combo (smart card reader with fingerprint sensor). These compare fingerprint images to data stored on the token/smart card. Fingerprint images taken by these devices are never "sent" anywhere — they are verified on the token/smart card to ensure the legitimate user is attempting to use that device. Fingerprint scanners have also been incorporated into some new smartphones (FOMA F900i ) and laptops (IBM ThinkPad T42).

Facial recognition is another well-understood biometric method. For example, the VISecurity BiometricsVIEW toolkit illustrated below translates a facial image into numerical samples that can be used on subsequent scans to authenticate that person. Facial recognition products must overcome differences that change a person's appearance, such as lighting, haircut, glasses and aging.