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