small corrective tweaks on the raging OTP debate

[hobbit () avian org (*Hobbit*)]

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*