Re: SecurID

[vin@shore.net (Vin McLellan)]

        Paul J. Bell <pjb@ny.ubs.com> gave a desperate shout for help:

>someone at my firm is about to press the securid system down our collective
>throats. please point me to the recent thread on this subject, and/or point
>me to some url's or the like, or to someone who has some firsthand
>knowledge of the pitfalls and/or vulnerbilities of secirid.

        I think Enigma Logic, Digital Pathways, and Cryptocard -- all
vendors of competitive one-time passsword (OTP) tokens --have diatribes
against the ACE/SecurID system on their web sites.  Check them out.  Over
the past two years, there have also been a number of fairly in-depth
debates about SecurIDs and the ACE protocols on the Firewalls mailing list
(ftp the archives at greatcircle.com) and in comp.security.unix. My SecurID
FAQ, available from SDTI at <http://www.securid.com> might give you ideas
too.

        Most people find the SecurID (and most of its competitors)
relatively well-designed and and secure devices.  Most of the negative
comment I've seen is from competitors who say the SecurID and it's ACE
support system is too expensive, and from ACE administrators who gripe that
the software is not optimized for their favorite platform.  It is
unfortunately true that SDTI  has not yet mastered the knack of producing
perfectly bugless code. Earlier this year SDTI also fouled up badly when
they failed to bring their Customer Support operation up to speed to
support a new generation of authentication servers (ACE 2.X) which involved
a relatively more complex Unix installation.  They've spent a lot of money
and hired a lot of people, but I don't think there is yet a consensus about
whether they've licked that.

        Still, some people think they get their money's worth.  SecurID is
the OTP token of choice at most (80 percent +) large corporate sites --in a
market with a lot of competitors, including well-done freeware OTP
alternatives: s/key and OPIE.  Of course, those buyers could all be wrong.

          SDTI's success is really built on the fact that users -- the
people who actually carry the tokens -- usually say they like the SecurID
better than the alternatives.  The SecurID claims the lion's share of the
market  because it is relatively intuitive and easy to use: the PIN and
token-code can be typed in like a (long) traditional password.  The
alternative tokens -- all challenge/response devices -- force the user to
engage in a multi-step process to get a random challenge from the remote
host, tap it into the token, encrypted it, then send it back to the host as
the OTP.

      SecurIDs are supported by an ACE authentication server which  --
alone among the OTP vendors -- holds its Access Control files in a
commercial-grade SQL-savvy relational database, which means that can be
interlinked with HR or any other SQL-savvy corporate RDBS.  As the industry
sets the stage for enterprise-wide IP security (hopefully soon to include
crypto) many  believe the authentication server's capabilities become more
important than the token's design.

        But, hey, those folks could be wrong.

        SDTI also just bought RSA Data Security, which some feel enhances
its prospects for making some further contribution to enterprise security.
Even before that, some 50 of the leading independent vendors of
network-based products (from firewalls and comm servers to big databases)
had chosen to integrate ACE/SecurID client code into a huge variety of
products.  This is a fairly unprecidented level of industry support -- but
they might be all wrong too.

        ACE/SecurID is notable among other OTP systems for both its support
infrastructure (STDI supported the client/server architecture five years
before any other OTP vendor,) and because it is a (patent-protected)
time-synched device: the 30/60-second dynamic token-code the SecurID
displays is a hash of Current Time and a token-specific secret seed. This
has pros and cons (honest,  both pros and cons;-)

        Unfortunately, what ACE/SecurID does not do -- what no OTP can do
-- is safeguard or secure your communications links.  (It also does not
minimize the need for ongoing system administration; capable auditing and
oversight; or an explicit local security policy -- all of which can also be
burdensome to the user.  But the real bear is network security.)  On an
unprotected network or telephone link -- in the face of a sophisticated
attack -- nothing but  network-level crypto or link encryption can stave
off either eavesdropping or active TCP "session stealing."

        (Several of SDTI's strategic partners do provide encrypted tunnels
through open networks. There are even some well-regarded freeware or
shareware options.) SecurIDs, like any OTP, only identifies the guy who
knocks on the front door.  This is useful; it's even important -- but it's
not enough.  Most environments need (but don't have) crypto too.  But even
in the face of this acknowledged threat -- session hijacking -- many sites
still find it useful to invest in OTP tokens, often SecurIDs.  They do this
because:

        * OTPs can offer a more-certain two-factor authentication
(something known; something held);
        * OTPs foil a whole array of trojan and sniffer-based attacks which
seek to collect the passwords of innocent users like yourself; and
        * OTPs can raise a partial barrier against network-based attacks.

        Effectively, OTPs force most network-based attacks to become
overt... so the user and/or sysadmin has a chance to recognize that
something is wrong and react defensively.

        Some believe the ACE/SecurID system actually does a little better
than that. The ACE protocol encrypts all packets containing user
authentication data as it passes between the ACE/Clients (often embedded
communication servers of various types) and the ACE/Server.  This
establishes an encrypted virtual net for authentication data with the user
site, which blocks another class of attacks.

        In an ACE/SecurID-protected environment, the threat of
network-based attacks is thus somewhat constained.  Authentication calls,
and the TCP/IP sessions they authorize, remain quite vulnerable if they are
transmitted over the Internet, or an extended private network, or telephone
links susceptable to physical wiretaps.  OTPs safeguard the authentication
calls against replay attacks --and most of the race attacks seem managable
-- but unencrypted sessions ultimately remain vulnerable to both
eavesdropping and session hijacking

        In many corporations, however, only a fraction of the data traffic
travels on these high-risk links.  While there are net-based attacks that
might reach in to grab unencrypted message traffic on your internal LAN (Is
someone is also trying to force a firewall on you guys too, PJ?) within the
ACE client/server environment, at least user authentication data -- name,
OTP, and PIN --  seems to be securely encrypted.  Not that there aren't
hackers -- and cynical system administrators -- probing and testing it
daily.

        Rumors and dark suspicious whispers abound, as seems inevitable
with any successful product that relies on crypto. (Actually, any widely
used computer security product -- have you noticed?) Personally, I find it
reassuring to remember that for virtually every flaw there is, inevitably,
a fix.  But then, Wall Street's recent soaring climbs and plunging drops
remind me of just how potent rumors can be.

        Please come back and tell us if you find any real dirt, Mr. Bell.
(And please pardon the blithe spirit that infected my comments. It's just
hard to play the straight man on a Saturday summer night.)  Also, an
obligatory avowal:  SDTI regularly pays me huge sums of money for
information and advice, but they ignore at least half of what I say.

        You can too.

        Suerte,
                        _Vin

         Vin McLellan +The Privacy Guild+ <vin@shore.net>
      53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548
                         <*><*><*><*><*><*><*><*><*>