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 is usually 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, but when you ask them about passwords, they know what you mean. Passwords are a battle. End users want passwords that are short and easy to remember. Security administrators want passwords that are long and difficult to crack. Even if the security administrators have their way, nothing will stop the proverbial Post-It note from appearing on a user's monitor with a long and difficult-to-remember password written on it.
Even if users keep their password secret, accessing passwords is possible if you do not change them regularly. A protocol analyzer can capture static passwords off the network. Someone with enough computing horsepower can break an encrypted password.
Security experts agree that the current password-generation method that corporate computing uses is not effective. The tremendous growth in the Internet (and intranets), telecommuting, and the soon-to-be ubiquitous market of electronic commerce magnify password confidentiality and security concerns.
An alternative to the current security approach is two-factor authentication: The user provides two items, a personal identification number (PIN) and a token code. The PIN is unique to each user and is encrypted when it is transmitted over the network or WAN. Think of the PIN as the security-equivalent of the PIN you use with your ATM card or credit card. A physical device called a token generates the token code. The token displays a new code every 60 seconds; therefore each token code is used only once.
Token-based authentication eliminates nearly all the risk involved with validating users in a network. Token-based schemes improve security, lower per-user cost, centralize and reduce administration costs, and minimize unauthorized access to services. A few major players that produce token-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 an example of a typical token-based authentication system, this article will explore the uses and functionality of Security Dynamics' ACE/Server software and SecurID token.
ACE/Server provides authentication services for network resources; audit and reporting utilities; realtime monitoring of logon and administrative activity; and GUI-based tools for administering the ACE system, the users, and the PIN and token-code database. The ACE/Server software 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 management functions from the server or from an NT workstation. ACE/Server provides enhanced security for both local 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-bit microprocessor, memory, a clock chip, and a lithium battery, and provides LCD output for the token code. The token is a sealed device that does not require battery changes. A token that lets you unlock it and replace the batteries is a significant security risk, so the microprocessor is designed 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. No one can calculate, guess, or otherwise determine the next or future codes from a record of past codes from that SecurID token. Determining a code is computationally impossible if you don't know the seed numbers that were entered for the proprietary one-way function (OWF) hash algorithm that calculates the code. The standard SecurID token runs for up to four years. During this period, it generates 4 million to 8 million sequential calculations. You can also preprogram tokens to terminate at a given date and time.
Each user is assigned a PIN that corresponds to the token. The PIN is between four characters and eight characters long and can be all numeric or a mix of numbers and alphabetical and typographical characters. Longer PINs obviously provide greater security against an attacker who tries to guess a user's PIN or who tries to read a PIN over the shoulder of a user working at a keyboard.
ACE/Server also supports a duress PIN in addition to the normal PIN. Users can enter the duress PIN if they're logging on under coercion. With a duress PIN, the user is granted access and sees no apparent 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 administrator sees 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 NT security box, and enter a logon name and a password. The ACE/Client presents a second window, as Screen 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 server knows the SecurID hash algorithm and has a database record of the secret key (the numeric seed) each token uses. When the server receives the authentication request, it validates the user's PIN from the server database and then independently computes the code for that user's SecurID token for the current 60-second window of time. The server then matches the resulting passcode against the passcode the user entered.
The ACE/Server system is time based (each passcode is valid for only 60-seconds), and each SecurID token has an internal timestamp. If 60 seconds is too large a window, you can implement 30-second passcodes instead.
Time synchronization is critical to prevent the ACE/Server system from calculating the wrong passcode. To allow for imprecision in the token's measure of the current time, the authentication server tracks, records, and adjusts for any historic time drift in each token's clock-chip. The server calculates a passcode not only for that current time but also for the 60-second time slot that preceded it, and the next time slot in sequence.
For a token-based authentication system to operate effectively, end users must know that the system is not a panacea. The ACE/Server system assumes the users will protect their PIN. After someone has the user's PIN and physical token, that person can masquerade as the legitimate user and gain system access.
Why Trust the System?
Security Dynamics does not reveal or publish details about the secret keys that the company programs into each token. That secrecy makes some security people a little nervous about potential flaws within the ACE architecture. The only public information provided about the secret keys is that each secret key programmed into a SecurID token is random and unique (no two tokens have the same secret key) and that each is significantly longer than the 56-bit key used in the Data Encryption Standard (DES). This approach implies that a brute force attack against the ACE/Server architecture 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 confidential information in a precarious position. A token-based two-factor authentication system can help keep your network secure.
|DSS NT Logon|
|AssureNet Pathways (formerly Digital Pathways)|
Email: [email protected]
|SafeWord Authentication Server & DES Gold Card|
510-827-5707 or 800-333-4416
Price: Contact Secure Computing for pricing
|ACE/Server, ACE/Client, and SecurID token Security Dynamics|
Price: Contact Security Dynamics for pricing