Skip to main content


Security Tokens - Buyers Guide and indepth Review

posted onAugust 13, 2001
by hitbsecnews

If your organization is like most, your users log into your enterprise system with user names and passwords. And they probably log into multiple accounts, with each account requiring its own user name-password pair. Some applications employ authentication, asking for another user name-password set, and now your users are up to their necks in passwords.

Single-sign-on systems can alleviate some password-management problems for end users, but single sign-on is expensive and complicated to deploy, and doesn't address the fundamental problem--the ease with which passwords are lifted via shoulder-surfing, by keystroke loggers and/or by a variety of other techniques. In contrast, security tokens can replace user name-password pairs or can be used in two-factor authentication schemes where authentication is dependent on the user having both an authentication token and a PIN/password. Authentication Times Two...

Security Tokens

August 20, 2001 By Mike Fratto writing for TechWeb's Network Computing

Authentication tokens function on two levels. First, only the authorized user should possess the token and the password that unlocks it. Second, tokens protect secret data--the shared secret or the public/private key pair--by performing cryptographic functions, such as key generation, key negotiation and authentication, within the token circuitry. Neither the end user nor the OS can access the shared secret or public/private key pair.

Two-factor authentication provides twice the assurance of a single password scheme that your users are who they say they are. The qualitative measurement goes like this: Single-factor authentication (password only) is easy to steal and, in turn, use. It provides minimal assurance that the person using that user name-password isn't an impostor. A user wouldn't know if his or her password had been stolen--after all, nothing physical is taken.

With two-factor authentication your users must possess both the tokens and the PIN/passwords to log on. A user would know if his/her token were stolen or missing. Therefore, adding tokens as a second layer to your security schemes may decrease the likelihood of an attack.

The integrity of a two-factor authentication scheme is wholly dependent on users handling their tokens and PINs responsibly, however. This involves not losing the authentication token, changing the PIN periodically and notifying the appropriate people immediately if the token is missing. If a determined attacker gets a user's PIN and authentication token, that user is easily impersonated--think of someone walking around with your PIN number and your ATM bank card. This exposure lasts from the time the token and PIN are stolen to the time the legitimate user notifies the appropriate authorities and the authentication token is invalidated.

Function Over Form

Authentication tokens come in many forms, including magnetic-strip cards, USB devices, micro-chip cards with readers, and contactless cards that use radio to transmit data. But the function of the token is more important than its form: The token is worthless if it doesn't do what's required.

Choose devices based on your application and policy needs. Some authentication tokens generate random passwords that are keyed into the authenticating application. Others generate and store public keys while holding the certificates based on the keys. Still others perform all cryptographic functions on the token. Additionally, the API will determine how easily you can integrate token authentication into existing applications. For example, Microsoft's CAPI (Crypto API) for Windows and RSA Laboratories' PKCS (Public-Key Cryptography Standards) #11 both define APIs for accessing tokens and let vendors integrate security products into the OS--token developers needn't write separate drivers for each application. Likewise, application developers should support any CAPI-, PKCS #11-, or PKCS #12-compliant token.

API and standards specifications can be interpreted, and misinterpreted, so vendor certification will add another level of assurance that authentication tokens and applications work together. Nearly all vendors have partnership certification programs; RSA Secured and the Microsoft Certified Partner program are two. Careful review of the certificate program and the products certified can clue you into limitations and potential problems when integrating products. Additionally, there are certification programs designed to provide assurance that token products perform securely.

Traveling users are limited to what's supported on today's laptops. Many laptops (including the IBM T21 I use) have USB, serial, parallel and mouse ports at the back of the case. But devices that are plugged into those ports can become misaligned or worse. And they can be damaged if deflected upward in the socket. For laptop users, the PC card or USB form are the best choices. Both are widely supported, offer plug-and-play connectivity and can be hot-swapped.

Microchip, magnetic strip and contactless cards all require external readers. Avoid this option with traveling users because often there is no place to lay the reader while in use. But if your road warriors must use external readers, laptop-to-reader interface options include PC Card, serial port and mouse-port adapters.

Desktop users have more reader-interface options. These interfaces are often on the back of the PC and require the use of extension cables to bring the USB ports or external card readers to a location where users can access them. Obviously, you don't want your users going butts up over a PC to plug in an authentication token.

Click here to continue reading this indepth look at security tokens at Network Computing

Source

Tags

Networking

You May Also Like

Recent News

Tuesday, July 9th

Wednesday, July 3rd

Friday, June 28th

Thursday, June 27th

Thursday, June 13th

Wednesday, June 12th

Tuesday, June 11th

Friday, June 7th

Thursday, June 6th

Wednesday, June 5th