Token-Based Security Add-Ons

Most network security systems rely on single-factor authentication. With this type of authentication,end users need only one item to verify the username they enter when they log on. This one item isusually a password, which often remains the same for a significant amount of time.

Most end users don't know what authentication refers to in the realm of computer security, butwhen you ask them about passwords, they know what you mean. Passwords are a battle. End users wantpasswords that are short and easy to remember. Security administrators want passwords that are longand difficult to crack. Even if the security administrators have their way, nothing will stop theproverbial Post-It note from appearing on a user's monitor with a long and difficult-to-rememberpassword written on it.

Even if users keep their password secret, accessing passwords is possible if you do not changethem regularly. A protocol analyzer can capture static passwords off the network. Someone withenough computing horsepower can break an encrypted password.

Security experts agree that the current password-generation method that corporate computing usesis not effective. The tremendous growth in the Internet (and intranets), telecommuting, and thesoon-to-be ubiquitous market of electronic commerce magnify password confidentiality and securityconcerns.

Two-Factor Authentication
An alternative to the current security approach is two-factor authentication: The user providestwo items, a personal identification number (PIN) and a token code. The PIN is unique to each userand is encrypted when it is transmitted over the network or WAN. Think of the PIN as thesecurity-equivalent of the PIN you use with your ATM card or credit card. A physical device called atoken generates the token code. The token displays a new code every 60 seconds; therefore each tokencode is used only once.

Token-based authentication eliminates nearly all the risk involved with validating users in anetwork. Token-based schemes improve security, lower per-user cost, centralize and reduceadministration costs, and minimize unauthorized access to services. A few major players that producetoken-based authentication solutions for the Windows NT environment are listed in the contact box.

The ACE System
Security Dynamics is a leading vendor of token-based authentication solutions. To give you anexample of a typical token-based authentication system, this article will explore the uses andfunctionality of Security Dynamics' ACE/Server software and SecurID token.

ACE/Server provides authentication services for network resources; audit and reportingutilities; realtime monitoring of logon and administrative activity; and GUI-based tools foradministering the ACE system, the users, and the PIN and token-code database. The ACE/Serversoftware runs under NT Server or various UNIX implementations and works with a client-side module,the ACE/Client. The software is optimized for NT, and you can perform all security managementfunctions from the server or from an NT workstation. ACE/Server provides enhanced security for bothlocal network logons and remote logons via Remote Access Service (RAS).

The SecurID token is about the size of a credit card, but thicker. It contains an 8-bitmicroprocessor, memory, a clock chip, and a lithium battery, and provides LCD output for the tokencode. The token is a sealed device that does not require battery changes. A token that lets youunlock it and replace the batteries is a significant security risk, so the microprocessor isdesigned to erase its memory if the token's casing is breached or otherwise subjected to attack.

The code a SecurID token displays is a pseudo-random number that changes every 60 seconds. Noone can calculate, guess, or otherwise determine the next or future codes from a record of pastcodes from that SecurID token. Determining a code is computationally impossible if you don't knowthe seed numbers that were entered for the proprietary one-way function (OWF) hash algorithm thatcalculates the code. The standard SecurID token runs for up to four years. During this period, itgenerates 4 million to 8 million sequential calculations. You can also preprogram tokens toterminate at a given date and time.

Each user is assigned a PIN that corresponds to the token. The PIN is between four charactersand eight characters long and can be all numeric or a mix of numbers and alphabetical andtypographical characters. Longer PINs obviously provide greater security against an attacker whotries to guess a user's PIN or who tries to read a PIN over the shoulder of a user working at akeyboard.

ACE/Server also supports a duress PIN in addition to the normal PIN. Users can enter the duressPIN if they're logging on under coercion. With a duress PIN, the user is granted access and sees noapparent difference in the system's response. But the system records the access in the audit trail,and the ACE/Server administrator's account is immediately notified of the event. The administratorsees a pop-up message or a message on a beeper. The administrator can then take appropriate action.

So How Do You Use a Token?
An ACE logon is similar to a standard NT logon. Users press Ctrl+Alt+Del to bring up the NTsecurity box, and enter a logon name and a password. The ACE/Client presents a second window, asScreen 1 shows, to prompt for a passcode, which is the user's PIN plus token code.

Authentication occurs when the ACE/Server recognizes the passcode. The authentication serverknows the SecurID hash algorithm and has a database record of the secret key (the numeric seed) eachtoken uses. When the server receives the authentication request, it validates the user's PIN fromthe server database and then independently computes the code for that user's SecurID token for thecurrent 60-second window of time. The server then matches the resulting passcode against thepasscode the user entered.

The ACE/Server system is time based (each passcode is valid for only 60-seconds), and eachSecurID token has an internal timestamp. If 60 seconds is too large a window, you can implement30-second passcodes instead.

Time synchronization is critical to prevent the ACE/Server system from calculating the wrongpasscode. To allow for imprecision in the token's measure of the current time, the authenticationserver tracks, records, and adjusts for any historic time drift in each token's clock-chip. Theserver calculates a passcode not only for that current time but also for the 60-second time slotthat preceded it, and the next time slot in sequence.

End-User Responsibilities
For a token-based authentication system to operate effectively, end users must know that thesystem is not a panacea. The ACE/Server system assumes the users will protect their PIN. Aftersomeone has the user's PIN and physical token, that person can masquerade as the legitimate user andgain system access.

Why Trust the System?
Security Dynamics does not reveal or publish details about the secret keys that the companyprograms into each token. That secrecy makes some security people a little nervous about potentialflaws within the ACE architecture. The only public information provided about the secret keys isthat each secret key programmed into a SecurID token is random and unique (no two tokens have thesame secret key) and that each is significantly longer than the 56-bit key used in the DataEncryption Standard (DES). This approach implies that a brute force attack against the ACE/Serverarchitecture is possible but such an attack would be extremely expensive and time consuming.

Security Is the Answer
Sharing information across networks and over the Internet can put sensitive and confidentialinformation in a precarious position. A token-based two-factor authentication system can help keepyour network secure.