[3355] in bugtraq
Re: SecurID White Paper - A Comment
daemon@ATHENA.MIT.EDU (Alan Cox)
Mon Sep 16 14:37:38 1996
Date: Mon, 16 Sep 1996 09:42:45 +0100
Reply-To: Alan Cox <coxa@cableol.net>
From: Alan Cox <coxa@cableol.net>
X-To: vin@shore.net
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@NETSPACE.ORG>
In-Reply-To: <v02130504ae5e255e652f@[198.115.177.207]> from "Vin McLellan" at
Sep 13, 96 07:10:28 am
> 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.
There is no major cost issue. ssh is free except for a small amount of
extra CPU load. Secure mirroring software using rsync and ssh exists.
> OTPs serve purposes other than safeguarding network TCP links from
> session stealing. In many organizations, these are seen as valuable
> functions. OTP tokens offer greater credibility to both audit and
OTP's don't help protect the important stuff. If someone does a session
intercept on your backbone router boy have you got some SERIOUS problems.
Worse with stuff like cisco's a UDP intercept including spraying the
router with a 1st tftp data block including a cisco password waiting for
a boot is just too easy MUCH too easy.
> 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
I think he is close to right. At the end of the day if you get broken into
you get broken into. The simple securID attacks demonstrated show the
weakness of a pure OTP. Other things show the weakness of pure crypted
channels.
> When a traveling executive accesses his e-mail server with SecurID
> over the Internet, he might possibly be hijacked. That might be
> embarrassing... but it's nothing like the danger involved in having a
> Pirate win access the corporate financial reports or development plans, for
> instance. That data, if on another server, could (even likely, would)
> require an _additional_ SecurID token code... or (perhaps best) might be
> simply unavailable through the ACE/Client which serves external network
> links.
Pity if someone emailed to to the travelling executive. Its better to have
blanket coverage simply because human beings make regular stupid mistakes,
even the best ones.
> first identifier, typically the user's name, as the answer needed to all
> race attacks. (Revising a protocol which has to remain backward compatible
> to ACE/Clients imbedded in some 200 network products from some 50 vendors
> is an interesting challenge;-)
You mean you forgot to include a secure download and reprogram of the client
units. Ah well
Alan
