Authentication Options

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.