From vin@shore.net Thu Aug 15 15:37:14 1996 Received: from relay1.shore.net (root@relay1.shore.net [192.233.85.129]) by suburbia.net (8.7.4/Proff-950810) with ESMTP id PAA14195 for ; Thu, 15 Aug 1996 15:35:35 +1000 Received: from [206.243.160.208] (slip-2-26.slip.shore.net [206.243.160.226]) by relay1.shore.net (8.7.5/8.7.3) with SMTP id BAA28213; Thu, 15 Aug 1996 01:34:09 -0400 (EDT) X-Sender: vin@shell1.shore.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Aug 1996 01:32:13 -0400 To: "Joel M Snyder" From: vin@shore.net (Vin McLellan) Subject: BoS: Ease of use of harware tokens (was Re: SecurID) Cc: best-of-security@suburbia.net, sdadmin@jabberwocky.bbnplanet.com In an exchange on C'punks, Vin McLellan wrote: >>> 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. On BoS, Greg Woods challenged McLellan point-by-point, with a checklist;-) but on this item said: >> 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. Joel Snyder jumped in and claimed to have an alternative to SecurID that escaped the irksome hassles of a real challenge/response protocol: >You should be aware that CryptoCard, which makes a DP-compatible token, >offers a "reduced input" mode which makes the amount of input equivalent >>to the SecurID token. We use CryptoCards in this mode with Cisco's >Secure/IP server and find that the additional convenience is worth the >theoretically larger additional hole. This is a reasonable decision, _IF_ you knowingly accept the particulars of the less secure protocol (what Mr. Snyder so obliquely refers to as the "theoretically larger hole") inherent in these "event-synchronous," or "semi-synchronous," or "reduced input" OTP systems. As I understand it, the way these devices work is that they take an initial, conventional, challenge/response exchange and then have the token hold, within its memory, the "response" after it has been used as an OTP. With the next authentication call, the "event-synch" token presumes or makes believe -- as the default -- that the "response" from the previous exchange, held in memory, is the a new "challenge," purportedly from the host. It then encrypts this stored value, within the token, and offers it as the ritual "response" -- the OTP, to be offered like a SecurID passcode -- while it stores the value of this new response as the presumptive "challenge" for the next logon cycle. Thus, as Mr. Synder notes, this scheme reduces the time, hassle, and keystrokes involved in a user's authentication to something "roughly equivalent" to the time involved in using a time-synch SecurID... but only because this scheme allows the user to forget about getting a random challenge from the host and encrypting it in the token (the initial steps of a traditional challenge/response sequence.) Cryptocard, Enigma, and the other prominent OTP token vendors are all reputable firms which offer solid challenge/response tokens. However, for the last 6-7 years -- ever since the idea of this scheme was first floated; then as now, an attempt to match the SecurID's ease-of-use advantage -- I have repeatedly argued that this "event-synchronous" protocol entails what I suggest are unacceptably high risks. (Humor me, as I continue the tradition, please.) In the first place, this is _not_ a two-factor (PIN/token) scheme. That may not mean much if you see if worry only about sniffers on your communication links, but inherent in the classical definition of two-factor hand-held authenticators is the _requirement_ that a user have a physical token in-hand (now!) in order to obtain the token-based OTP that is used to complement a memorized PIN: "something known," and "something held." There is a reason for this. The one-time password (OTP) addresses one threat. The requirement for two-factor authentication addresses an entirely different audit/management objective. With these "event-synchronous" tokens, the user can sit down and punch out the next half-dozen valid OTP codes (each using the stored value of the prior response as the purported "challenge" in the next calculation.) A user could leave the token at home and just carry a list; he can even distribute them to three or four other people to allow them to access his account. For the penny-pincher, one event-synch token can be used to provide authentication to a whole office. (And then there are the criminal or conspiratorial possibilities....) Consider: the "event synch" protocol effectively frees the OTP from the token which generates it. And -- in doing away with the "spontaneous" pseudo-random challenge from the host -- it also cuts the authentication exchange loose from the timely context inherent in any traditional challenge/response exchange. This pseudo-C/R authentication scheme would seem to be -- potentially, at least -- vulnerable to race attacks that traditional C/R authentication is relatively secure against. Then there is the question of implementation. Theoretically, so long as a pre-calculated list of token-codes has them used in sequence, each token-code from an event-synch token is a valid authentication code and will be accepted by the server. In fact, however, at least with the Enigma authentication server -- which is often what Cryptocard users depend on, since Cryptocard produces only tokens and a Windows-based server -- the implementation of "event-synch" seems to be even more forgiving. With Enigma's server -- Safeword AS for Netware -- and CryptoCard's RB-1 token in "event-synch mode" (as well as Enigma's Silver or Multi-server cards, and their SofToken) you can punch out the next several valid OTP codes -- 1,2,3,4,5,6, -- and use them in sequence. Or, you can skip one -- use #2, #3 and then #5, #6 -- and the server will still accept them. Or you can skip five -- use #1, and then #6 on your list -- and the Server will still accept them. The sequence matters, but they do not have to be used serially. Doubtless it's a feature for fumble-fingered users who push the token out of synch, but it further loosens any linkage between the token and the OTP. There are certainly, as Mr. Snyder declares, sites where a fully-informed choice of this level of authentication security is appropriate. (Anything is better than the reusable passwords still in widespread use!) There may be many sites where making the presence that the physical token "optional" at logon is of no real import. Other sites, particularly business environments, may depend upon the enforced presence of a token (and the additional certainty two factors bring to OTP authentication) to hold employees accountable for their actions online. In a corporate environment, an IP savvy auditor might say that to sacrifice both the spontaneous and random "challenge" from the host -- and the requirement that the user hold the physical token to generate the OTP at logon -- is to sacrifice too much... just to try to match the SecurId on ease-of-use. And if he has heard me gripe about this over the years, he might add that what is lost in the credibility of the user's ID authentication is worth much more than the couple of bucks per-token saved. Of course, maybe I should also repeat what I wrote in the original message: Many people, and I among them, believe that the capabilities of the authentication server (and particularly its database) are now more important -- or should be more important to potential buyers -- than the ease-of-use issue and the token's design. Still, there are interesting footnotes to the suggestions that were made for alternatives to SecurIDs. noted: >|A french company makes a device called an Active Card. I've only played >|with it but it seems pretty nice. See http://www.activcard.com for >|details. It has an optical coupler and if I remember right can >|scan it's challenge off a screen and with the optical coupler >|can also send the response. Yup -- and veterans of this industry might recall seeing several of those nifty features on other products which were, curiously enough, described as "patent-protected." In the US -- and I'd expect in many other jurisdictions -- the decision to purchase ActivCard devices is complicated right now. ActivCard S.A., and ActivCard, Inc., have been sued for patent infringement (US Federal Court, Northern District of California) by both Security Dynamics Technologies, Inc., and Vasco Data Security, Inc. The case is being prosecuted vigorously by both plaintiffs, and the short-term and/or long-term availability of ActivCards might be... ummm, let us say, uncertain. Rob Waters also suggested: >| Wouldn't the easiest solution be to design the token so that the number >| could be read from the LCD, but that the token could also be inserted >| into a floppy drive and read automatically by applications that could >| talk to a PC? Cryptocard and SmartDisk got together and developed a neat device on a design close to this; it's now sold as Cryptocard's SB-1 hand-held authenticator. It remains to be seen if this extremely clever design -- a combination boot lock, disk encryptor, and challenge/response authenticator, all in SmartDisk's pseudo-floppy-disk format -- will be accepted by buyers and users, in the face of the many new PCs with pre-installed PCMCIA slots. I like it, but SDTI and most other OTP vendors seem to be betting on the PCMCIA form-factor. SDTI and Motorola have already jointly developed a PCMCIA card which is both a (cellular-capable) v.34 modem and a SecurID, and there are doubtless several other PCMCIA authentication-plus products in the pipeline. RFC: Flames are a fact of life, but any Corrections of Fact in reference to the stuff above would be gratefully accepted. I've been a consultant to SDTI for many years, but I like to think my opinions and my errors are my own. My SecurID FAQ is available at http://www.securid.com. Suerte, _Vin Vin McLellan +The Privacy Guild+ 53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548 <*><*><*><*><*><*><*><*><*>