Quote:>>Not only is chat useful with SecureID, but I am using it now.
>>The key is to not type in a password that is about to expire. The
Quote:>Actually, I've found that using an "about to expire" password works just fine.
>I don't know about your case, but our server seems to have a "grace period"
>where it will allow the last password to be used even though it's expired.
>This allows for the clock in the card and the clock in the server to be
>out of synch with each other. In fact, I'm guessing that it keeps a sequence
>of pass numbers and then uses an algorithm based on how long ago you last
>connected to synchronize the servers clock with the card.
>It'd kind of have to... I've never had a "false" failure to log in via the
SDI's ACE software -- the software than manages and support the SecurID
tokens -- maintains a running record of the relative 'drift" in each
token's clock-chip, compared to the clock in the host or authentications
server. The database is updated each time a SecurID is used.
Working from this record, when an ACE authentication server receives a
name or employee number (the first discrete identifier in an incoming
authentication call) it pre-calculate the appropriate "token-code" for
what it expect's the token's clock chip to believe is Current Time, and
(just to be on the safe side) one 60-second time-slot fore and aft.
Thus, an ACE system will at any given moment accept three (3) SecurID
token-codes as valid, if it is accompanied by a valid user-memorized PIN.
And each token-code, as you doubtless know, is a pseudo-random number,
which is to say that having one will not allow you to guess or calculate
The ACE system does record all token-codes as they are used -- a
SecurID token code can only be used once, period -- but, no, it does not
calculate all token-codes for all supported tokens continuously. (Each
SecurID does keep calculating and displaying the ongoing PRN token-code
The SecurID token-code is calculated by putting the token's Current
Time and a token-specific Secret Key or "seed" through a SDI-proprietary
one-way function, a cryptographic message digest. The token-code is the
There is one search mode, but it is not an authentication mode.
The ACE database keeps a record of each token's use, and if a token has
not been used for a prolonged period (two weeks to two months, the
sysadmin decides)... and a valid PIN is submitted with an invalid
token-code, a special scan mode kicks in to minimize "false rejections"
due to clock drift.
Essentially, the ACE system -- working from what it's database
suggested the token would use as Current Time -- calculates a series of
"token-codes," searching for a match to the one submitted by the user. It
can only search ten time-units (30 or 60 seconds each) in either
direction, and typically the search is far more constrained at the
direction of the sysadmin.
If it finds a match for the submitted token-code, it adjusts it's
database record on the token-clock's drift pattern, and then invites the
user to submit yet another token-code. The SDI guys used to call it a
"Next PRN" call.
If you've got any serious question, you might check out their web site