From woods@ncar.UCAR.EDU Tue Aug 13 06:51:26 1996 Received: from ncar.UCAR.EDU (ncar.ucar.edu [192.52.106.6]) by suburbia.net (8.7.4/Proff-950810) with ESMTP id GAA06963 for ; Tue, 13 Aug 1996 06:49:32 +1000 Message-Id: <199608122045.OAA11820@ncar.ucar.EDU> Received: by ncar.ucar.EDU (NCAR Local/ NCAR Central Post Office 03/11/93) id OAA11820; Mon, 12 Aug 1996 14:45:57 -0600 (MDT) Subject: Re: SecurID To: vin@shore.net (Vin McLellan) Date: Mon, 12 Aug 96 14:45:56 MDT Cc: best-of-security@suburbia.net, sdadmin@jabberwocky.bbnplanet.com In-Reply-To: ; from "Vin McLellan" at Aug 11, 96 1:29 pm From: woods@ucar.edu (Greg Woods) X-Mailer: ELM [version 2.3 PL11] > Most people find the SecurID (and most of its competitors) > relatively well-designed and and secure devices.... ...this is the beginning of a marketing pitch for SecurID, in which the claim that SecurID has sold the most so it must be the best is repeated in several different forms. Everyone should bear in mind that this same argument can be used to prove that DOS is the best operating system on earth. I don't buy it from Bill Gates and I don't buy it from Vin either. What "selling the most" proves is that SDTI (and Micro$oft) got their hooks in early (for which they deserve credit) and have very aggressive marketing campaigns. This doesn't mean their product isn't any good, but it doesn't prove that it's the best for your environment either. > Most of the negative > comment I've seen is from competitors OK, I'm a customer. Granted, a small one. But I'm a customer of both SDTI and one of its competitors and I've used both in production. I don't care much for SecurID, and I'll try to explain why. This is nothing personal against Vin, who has been nothing but helpful on this list, and I still listen to what he says because despite my personal opinion about it, I still have an ACE server to administer. It's more that I think everyone should have the opportunity to hear the other side of the story. I'll start by saying that it has nothing to do with the relative security of the algorithms used by SecurID or its competitors even though that issue has received the most discussion here. I think the biggest weaknesses of OTP tokens, as Vin seems to agree, are in eavesdropping and session takeover attacks. This applies equally well to SecurID or its competitors. If I were a hacker trying to break into a site protected by OTP's, I wouldn't bother trying to crack the code, I'd just wait for someone to log in and steal the session. No need to crack the code. > who say the SecurID and it's ACE > support system is too expensive I say that too. Between the purchase fee for the ACE server software and the per token license fee, SecurID costs nearly three times as much as Digital Pathways, given that with with DP I can use freely available authentication server software. > and from ACE administrators who gripe that > the software is not optimized for their favorite platform. As an ACE administrator, this isn't even close to the top of the list of my concerns. My concerns are more along the lines of: 1) Multihomed clients don't work; 2) Multihomed servers don't work (is that true?); 3) There is no batch interface to the administration, so I must use cumbersome menus; 4) The tokens are disabled far too easily by naive users (we've got a bunch of them here) who do things like try to open three windows at once; 5) We can't order extra tokens to have instant replacements for lost tokens without paying an additional license fee. Now that we've had one die, we're finding it to be a major pain and taking far too long to get a replacement; 6) There is no way to set the PIN without either accepting a randomly-assigned PIN or using sdshell (the former is annoying, the latter is really a pain when the people who have the SecurID tokens use them only on cisco routers); 7) Just to even test the SecurID product here required the signing of lengthy legal documents containing many provisions that our Contracts department found unacceptable (they wanted us to pay shipping and to pay certain taxes for them). It took two weeks of negotiations just to get a few cards and an ACE server on a trial basis. > It is > unfortunately true that SDTI has not yet mastered the knack of producing > perfectly bugless code. I don't fault them for having bugs in their code. I don't write perfect code either. I do evaluate how they respond to bugs in the code. They've known about the multihomed client problem for two years at least, and have done nothing about it. > 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. Here I have to concede the point. Our Consultants also believe that the SecurID token will be easier to support in the hands of the users. My experience is that the challenge/response tokens are only a small amount of extra hassle, but I also know how upset users can get over the smallest hassle. Still, I have to believe that if the hassle of using OTP's at all is imposed on them, this extra difference is really minimal by comparison. > SDTI also just bought RSA Data Security And this shows that SDTI can see the writing on the wall. On the Internet, where users frequently come in over networks where the security is not guaranteed, OTP's are insufficient. Most of us know that encryption is the way to go. Those who demand the highest level of security will want both encryption and OTP, and SDTI knows it. > 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 I would say that if someone is able to sniff this traffic, you're dead already. Granted, this helps defend against a malicious user on the inside, but if you've got one of those, you've got a personnel problem, and it's unlikely that technical solutions are going to fix it for you. > reassuring to remember that for virtually every flaw there is, inevitably, > a fix. When are multi-homed clients going to work? In my mind, as a customer, that's a flaw. It hasn't been fixed. SDTI's attitude toward this problem has not been reassuring. > Please come back and tell us if you find any real dirt, Mr. Bell. If you're going to find dirt, you have to dig in the right places. IMHO, if you want to evaluate the various OTP products, if you're looking at the security of their password choice algorithm, you're barking up the wrong tree. --Greg