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.
Two-Factor Authentication
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.
End-User Responsibilities
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.
