lls @
GreatCircle .
com
Cc: malex @
kersur .
net, adam @
homeport .
org, hobbit @
avian .
org, mcn @
EnGarde .
com,
mudge @
l0pht .
com, peiterz @
SECNET .
COM, BUGTRAQ @
NETSPACE .
ORG
Organization: The Global ScoutNet Organization
Michael Alexander <malex @
kersur .
net> dropped me a pithy note,
which I quote in full:
>[oration given while standing on a soap box 10 feet high]
>
>So, does this mean you agree or disagree with Neuman and the rest?
Ouch! <sigh>
Mike Neuman <mcn @
EnGarde .
com> was right three/four years ago when
e, and the state of the art
-- and/or the IETF or Microsoft -- will lead us all to encrypt, all of the
time. (I presume this has something to do with why SDTI bought RSA.) The
question is whether someone is today a fool to install SecurID or some
other two-factor OTP system. Mr. Neuman has argued, for some time, that he
is. I disagree.
My point is: the decision to encrypt should be (must be!) a local
decision by someone who considers the value of what's at risk, the cost of
crypto, and the problems and economics involved in using, maintaining, and
the threat of session hijacking grows -- and with the
publication of attack code in 2600 and Phrack, and the distribution of
powerful freeware packet-manipulation tools like Netcat, it might be about
to explode -- more of us will doubtless choose to buy link or
application-level crypto. But it is, and should always be, a cost/benefit
calculation. Not a bribe to keep the boogieman away.
Despite anecdotal evidence and the acknowledged vulnerability of
the TCP/IP network, but blunt fact is that session-stealing on TCP network
links has apparently not yet led to attacks numerous enough, or serious
snatched
reusable password) getting unlimited future access: a key to the vault.
Mike Neuman -- more terse than I; and probably better-looking as
well -- responded with his customary confidence:
> Here's the reason you're wrong, and the reason one time passwords without
>encryption should be completely avoided:
>
> What is the primary value of One Time Passwords? To eliminate the possibility
>that a sniffer can steal a password and reuse it. All other benefits are
>tertiary (i.e. To prevent password guessing? Most systems have limits on
>the number of guesses before an account is disabled. To prevent password
-- to a high degree of certainty -- that the person who was issued that
token did initiate a particular online session. Despite what it doesn't
do (i.e., secure the network,) what it _does_ do is valued by many CIOs,
auditors, etc.
Mr. Neuman asserts that SecurIDs provide "no additional benefit"
over reusable passwords when used on a cleartext Internet connection. I
suggest this overstates his case considerably, in light of the current
prevalence of stolen passwords and replay attacks. [I'm also a little
confused at the wording he uses to dismiss or devalue OTPs in dial-up
, routing,
internal firewalls, multiple levels of authentication, restricted
applications, etc. -- that a net security manager can use to minimize his
vulnerability to an known attack along a given route.
Not all data links are TCP; and not all TCP links are equally
vulnerable. I noted earlier that the overwhelming majority of OTP
two-factor tokens are today used to safeguard dial-in phone links,
typically through a comm server of some type. Many sites -- quite
reasonably, it seems to me -- believe that these installations are
considerably less vulnerable to TCP-splicing than open network links, since
rks... but the installed base
of OTP tokens, and current buys, are still largely supporting dial-in
links.
(Another market artifact: the OTP salesmen I talk to tell me the
growing interest in encryption on network links is largely pushed by the
users' demand for confidentiality... not any concern from the CIO or
corporate security mavens about session hijacking. CIOs are all bred in
Missouri.)
Internal networks are also often seen as less vulnerable than
Internet links. Although both may be, technically, equally vulnerable to
both sniffing and session hijacking, insiders are feared less than
P
system. DPI offers only remote access control -- generally through a comm
server or modem -- but for a Unix environment, both Enigma and SDTI, e.g.,
typically demand authentication, and control access, by the server.
For a Netware environment, I believe Enigma provides remote access
control. SDTI provides both remote access ("gateway" control, typically
for a comm server on the phone line) as well as server-based ACE/Clients,
at least in the Netware 3.X environment. So a Netware user will generally
face repeated demands for SecurID authentication as he or she requests
managed to pull off a race attack
-- although, personally, I have always favored a longer wait-loop than the
2-second cycle used as the variable default on ACE/Servers (during which,
identical, or nearly identical, token-codes are recognized and both are
blocked.) And, of course, I too look forward to the rewrite of five
year-old ACE protocol -- long promised and soon due -- which I will expect
will lock down a user's record when the authentication server receives the
first identifier, typically the user's name, as the answer needed to all
race attacks. (Revising a protocol which has to remain backward compatible
e been a regular consultant to SDTI since
the late Bronze Age, in addition to being the author of the SecurID FAQ.
(New version soon to be available at: <http://www.securid.com>) I have
also been an advocate of OTP tokens since long before any arrived on the
market, and I remain deeply committed to the value of two-factor user
authentication.
PeiterZ also expressed umbrage that I had referred to his
associates as "elite hackers." I willingly apologize to PeiterZ, *Hobbit,
Adam Shostack, and the associates of LHT Industries: Brian Oblivion, Space
Rogue, Tweety Fish, Kingpin, Tan, Tom Icom, Veggie, Alice, Weld Pond, Dr.
d+ <vin @
shore .
net>
53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548
<*><*><*><*><*><*><*><*><*>
|
|
