> SDI's SecurID, a HHA which holds an
> estimated 80 percent of the Blue Chip (1500+ users/site) market for OTP
> security tokens.
What percentage of the personal computer software market does MicroSoft
hold? This hardly means that the product in question is the "best" product
in any real sense. In both cases here, it means only that the product
is the best marketed. Granted, market share does not condemn a product
either; I am just skeptical of (implied) claims that since product X has
80% of the market, it is therefore the best product. It does, however,
make life tough for those of us who happen to disagree with the claim,
since 4 out of 5 people out there are likely to disagree.
> users, if given a voice, generally prefer the SecurID two-factor
> authentication system -- just because it saves them a couple of minutes
> (and a dozen keystrokes and taps on a token keypad) every time they logon.
Your users are sure slow typists. While I agree that the preference is
there, it's more like a couple of seconds than a couple of minutes. In
our case at least, the difference between the "open" environment and one
in which they are no longer allowed to freely use "rsh" and "rcp" is so
much larger than the couple of seconds difference upon login between the
different OTP tokens that the latter difference is really insignificant.
> With TS
> tokens, the complexity is relegated to the ACE software; the cost is a few
> cycles of machine time. With C/R, the complexity is at the user's desk,
> and the cost is in all those extra keystrokes. And a widespread urge to
> somehow end-run the security system or avoid it all together.
Again I think you exaggerate the difference. The desire to end run
the security system will be just as strong no matter which token we employ.
> There are a variety of alarm and security formulas, some hardwired,
> some adjustable by the sysadmin, which determine how the ACE/Server handles
> inaccurate PIN and/or inaccurate card-codes.
My problem with this is not in whether or not the security of it is
adequate; I'm willing to accept that it is. It's just that when this
situation occurs, if you don't happen to be running the "sdshell"
program and are instead using something else that uses the supplied
library calls (such as "sdi_next"), it's a real pain in the butt.
This (among other things) makes it very difficult to use SecurID
in any authentication context other than "sdshell". IMHO, this severely
limits the usefulness of the product in an environment where flexibility
and many different points of authentication is desired.
The administration of SecurID is also a real pain. You have to use
their menu-driven interface. There is no batch or API interface
provided and therefore no way to integrate SecurID into our own
database. The few seconds per login of user time saved with SecurID
will be more than lost in administrator time. Their idea of a "fix"
for this problem, when I asked them about it, was that they would fix
an existing bug that didn't allow you to pipe the proper menu responses
into the administration program. This strikes me as a very kludgy way
to solve this problem.
> That request for two sequential PRN card-codes is used (with the
> user's PIN) in a new authentication cycle.
It's also a pain in the rear if you are trying to use SecurID authentication
from within any kind of homegrown application.
And lastly, let's not forget price. I found SecurID to be at least
double the cost of, say, DIgital Pathway's "SecureNet Key" (SNK) product,
since you have to license their proprietary software and replace the entire
token every few years. SNK works with publically available software (such
as the TIS authentication server) and the battery can be replaced for
a couple of bucks at Radio Shack without having to replace the entire token.
Just a few words from the other 20%,
--Greg
References:
|
|
