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.