From proff Fri Sep 20 17:49:49 1996 Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id RAA20860 for best-of-security; Fri, 20 Sep 1996 17:49:49 +1000 Received: (sendmail@localhost) by suburbia.net (8.7.4/Proff-950810) id NAA04395 for ; Fri, 20 Sep 1996 13:57:17 +1000 Received: from relay1.UU.NET(192.48.96.5) via SMTP by suburbia.net, id smtpd31731aaa; Fri Sep 20 02:07:34 1996 Received: from miles.greatcircle.com by relay1.UU.NET with ESMTP (peer crosschecked as: miles.greatcircle.com [198.102.244.34]) id QQbhxn11489; Thu, 19 Sep 1996 21:54:44 -0400 (EDT) Received: (majordom@localhost) by miles.greatcircle.com (8.7.1-lists/Lists-960417-1) id MAA09822 for firewalls-outgoing; Thu, 19 Sep 1996 12:24:23 -0700 (PDT) Received: from narq.avian.org (wet-string.avian.org [199.103.168.126]) by miles.greatcircle.com (8.7.4/Miles-960830-1) with SMTP id MAA09755 for ; Thu, 19 Sep 1996 12:23:58 -0700 (PDT) Received: from work.avian.org (work.avian.org [10.1.1.3]) by narq.avian.org (8.6.12/_H*) with ESMTP id OAA02900; Thu, 19 Sep 1996 14:22:33 -0400 Received: (from hobbit@localhost) by work.avian.org (8.6.12/_H*) id OAA01008; Thu, 19 Sep 1996 14:23:09 -0400 Date: Thu, 19 Sep 1996 14:23:09 -0400 From: *Hobbit* Message-Id: <199609191823.OAA01008@work.avian.org> To: firewalls@greatcircle.com Subject: small corrective tweaks on the raging OTP debate Sender: firewalls-owner@GreatCircle.COM Precedence: bulk Approved: proff@suburbia.net It has taken me a while to catch up on and mull over all this ongoing exchange about SecurID and related, from before the Weaknesses paper and afterward. I do not follow the sdadmins list, where some of the discussion has apparently happened without the context thereof being fully re-established on lists that I *do* read. Since I have been sort of dragged into this anyway, at least by name only, I have a few comments but they are fairly minimal and geared toward rectifying some incorrect statements and assumptions. None of this is meant to imply in ANY way that SDTI is selling snakeoil; the relative strengths and weaknesses thereof have already been more than adequately brought forth and hashed over. I am somewhat dismayed by the overtones of personal and political infighting, but overall it's been interesting. If I've said it once I've said it a hundred times by now, including right there in the README: Netcat is *not* a "packet manipulator" tool. It does not do TCP splicing or any other wire-level stuff. It is limited by whatever the generic user-level BSD sockets interface provides, and doesn't even explore the entirety of *that*. The fanciest that netcat gets is binding to source ports and loose source-routing, whoo whoo. For a good belly laugh, review the README and then read http://www.lantimes.com/96aug/608b016a.html. Never denigrate the merits of exploring the esoteric. However theoretical or mental-masturbatory the study of a security system may be, if someone wants in badly enough they will *implement* the esoteric attack via any possible means, and you lose. It is far more worthwhile to learn from the discussions and fix our systems accordingly, rather than mumbling "won't happen here" from somewhere under the surface of the sand. To propose a generic scenario that does not mean to pick specifically on SDTI: Tomorrow morning the attacker will connect to your wire where it passes through the cozy safety of his janitor closet, and playing ARP games will get him the half-minute of ACE server master/slave split he needs to follow you right into that secure database server with the same passcode you just used. Don't count on the successful attacker needing a lot of "hijacked" time to work, either. The attacker's first action before even looking around inside the vault will be to take the lock apart and remove enough of the innards to make future entry much easier. He doesn't *need* a key to the vault, and since the lock still seems to work normally you won't notice unless you are keenly attuned to its subtler characteristics. If you haven't read "rootkit" yet please go off and do so; it's rapidly becoming a classic work. By the time the hosed user is reaching for the phone, the attacker has been in and gone for the time being, and your lock parts are lying in a nearby storm drain. It has been repeatedly pointed out, perhaps somewhat obliquely, that using OTPs from or through any public ISP should be classed in the same risk category as using reusable passwords. I want to emphasize this, and add that there are an awful lot of newbies in the ISP business who barely understand the concept of a 3-way handshake let alone that session hijacking even exists. One can hardly expect such people to be genuinely up to speed on securing their own machines. They can't spend any time learning about Kerberos or reading MD5 change logs because they're way too busy making customer web pages look spiffy. Would YOU hire an advertising agency to install the burglar alarm in your house? No, one hopes that you'd hire a real security company. Crypto is cheap. Deploying the necessary KM infrastructure is the tough part, and hitherto every scheme for doing so seems fraught with its own set of annoyances and problems. It is also easy to screw up, as we hear about in a major way almost weekly. It is unfortunate that expending the needed thought and effort is so often *way* over the top of what the middle-management suit needs to check off the "computer security" box on his project plan. Hey, at least that new vault door *looks* great. Finally, at no point was I genuinely *involved* in the research behind the paper although if time permitted it would be *way* tempting. It is further being assumed, and somewhat simplistically stated, that I and select others are *involved* in the hacker community. First of all, most of us here understand the broad and fuzzily indistinct line between white hats and black hats. Those that do not currently understand that concept will have to for now accept at face value that they eventually will. Yes, I rub elbows with people who probably consider themselves members of one or another "hacker community" for whatever that moniker is worth and whatever the reader's preferred definition of "hacker". Translated, I associate with other people who enjoy solving puzzles and problems as I do, many of whom are better at it than I. Folks in these circles seem to almost universally adopt a fairly no-bullshit approach toward those who present "hard" problems that later turn out to have trivial solutions or undocumented secret shortcuts. The process by which such trivial solutions are determined, observed, reverse-engineered, defended against, or what have you is something I find endlessly fascinating. If this makes me or anyone else "hacker elite" in the eyes of some, so be it. Like many other readers here I freely scoff at those who profit from peddling such lame, easily solved problems to the unwary by simply asserting that the problems are difficult. Perhaps this is perceived by some as fence-sitting -- again, so be it, although the fence should really be viewed more like the median strip of an interstate. I don't enjoy seeing the public lied to either, and my interest in any of this is purely technical. _H*