Firewall Wizards mailing list archives
Re: Hardware tokens for remote access authentication
From: "Marcus J. Ranum" <mjr () ranum com>
Date: Mon, 12 Jul 2004 19:33:15 -0400
Vin McLellan wrote:
See Kevin Kadow's April '99 post to Bugtraq, "FWTK, Gauntlet 'random seed' security >problem," at: <http://www.securityfocus.com/archive/1/19990416203627.15201.qmail>.
Wow!!! This says something interesting about the value of full
disclosure, when you consider that the one person who most
likely should have seen this - didn't. ;) It also is interesting that
the report is '99 against code from '94. So much for the "many
eyes" theory of open source. ;)
Kadow's attack is heavily reliant on shell-level access to the
auth server. Anyone who gave shell-level access to their auth
server has already voided the warranty. ;) You're not supposed
to do that!!! Kadow's at least intellectually honest enough to
mention in his writeup that normal FWTK/Gauntlet configuration
practice is to only allow connections to authsrv on the loopback
port, which completely defeats the attack unless the attacker
is ON the machine. That's how it was designed to be run, and
that's how it was configured in Gauntlet. In other words, the
attack would never work against a system that had not already
been misconfigured to the point of stupidity.
Your posting, Vin, doesn't mention these inconvenient facts as
they are described in Kadow's own paper. That makes it sound
a lot like you're just blowing FUD to me. I understand your
desire to relentlessly market SDI's products (you took a couple
more chances to throw in a plug here and there in your response..)
but I don't think it's proper to do it at the expense of other
systems, by selectively choosing parts of someone else's
paper that subtly change the message and distort its meaning
just so you can make your point. That's not proper.
The _actual_ URL (the one Vin gave is wrong) is
http://www.securityfocus.com/archive/1/13322
and I suggest that anyone who is interested in this topic
give it a read - compare Vin's selective editing with what
Kadow really has to say. SHAME ON YOU, VIN!
I'm also not particularly impressed with hype and FUD
blowing "security researchers" who write a paper that
reads basically, "If the system is configured correctly
or in the default configuration as it comes from the vendor
this attack won't work" - who then goes on for 5 pages
about the theoretical ramifications of how serious the
attack would be, if the system were set up wrong. Duh!
You also need to be in the path where you can sniff
valid challenge/response pairs, in order to mate the
correct challenge with the right 56-bit DES generated
response. Well, if you can do that, since fwtk didn't
do user-land crypto, you can just as easily cut to the
chase and do an IP splice attack. That was a known
problem in the system that we ignored in 1994 because
"that'd be too hard" (or so we thought, then!) ;)
All that said, the PRNG seeding *IS* bad. The intent of
the system was to be 'good enough' to raise the bar
to the point where the bad guys would attack a weaker
part of the system - most likely the endpoint(s).
If you're willing to think about the problem for a few
minutes and not be impressed by FUD from a vendor
shill, you'll realize that moderately good authentication
raises the bar to the point where the other weaknesses
of the system become more significant. In fact, I'd argue
that plain-ole-passwords over SSH/SSL have probably
raised the bar to the point where the hackers are just
now having to re-invent transitive trust attacks (hello, kiddiez!)
The value of authentication systems like an SNK or
S/Key or SecurID has relatively little to do with their
cryptographic strength or complexity, and a lot to do
with the fact that hackers don't have keystroke loggers
for brains - yet. I'd go so far as to say that the ONLY
value of those systems is that they, for the time being,
push authentication computation into a non-networked
system. You can accomplish that with a palm pilot or
darned near anything, and you'll have a system that
the hackers aren't going to compromise.
Unless you give them shell access to it. Duh!
mjr.
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Hardware tokens for remote access authentication Bill Kyle (Jul 08)
- Re: Hardware tokens for remote access authentication Marcus J. Ranum (Jul 08)
- Message not available
- Re: Hardware tokens for remote access authentication Marcus J. Ranum (Jul 13)
- Re: Hardware tokens for remote access authentication Vin McLellan (Jul 13)
- Re: Hardware tokens for remote access authentication Marcus J. Ranum (Jul 13)
- Re: Hardware tokens for remote access authentication Vin McLellan (Jul 13)
- Re: Hardware tokens for remote access authentication ArkanoiD (Jul 15)
- Re: Hardware tokens for remote access authentication ArkanoiD (Jul 15)
- Message not available
- Re: Hardware tokens for remote access authentication Marcus J. Ranum (Jul 08)
- <Possible follow-ups>
- RE: Hardware tokens for remote access authentication Woeltje, Don (Jul 10)
- Message not available
- RE: Hardware tokens for remote access authentication Marcus J. Ranum (Jul 13)
- Message not available
