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 <*><*><*><*><*><*><*><*><*>