Firewall Wizards mailing list archives
Re: Hardware tokens for remote access authentication
From: kadokev () soak msg net
Date: Thu, 15 Jul 2004 01:55:08 -0500 (CDT)
Vin writes:
3. I went off and dug it out Kevin's Bugtraq post at Marcus' explicit request. This is a five year-old bug report about 10 year-old code -- almost surely a long-settled historical tidbit, I thought, with no competitive or commercial relevance in 2004!
I'd almost forgotten about this "tidbit" myself! That was not only my first real Bugtraq post, but also my first experience with a truly uncooperative vendor. Yes, the *published* proof-of-concept was made significantly easier by direct access to the "authsrv" TCP port and some visibility into the current process ID on the server. However, the underlying PRNG flaw did make several other attacks feasible, primarily due to the significantly reduced challenge space. Not only SNK was at risk in Gauntlet, but also Cryptocard and CHAP. If services through the firewall (proxies such as telnet, HTTP, FTP, etc could be set to require authentication, inbound from the Internet), access could be obtained to a service which was intended to be protected by strong authentication. Mike Scher and I had put some work towards more esoteric attacks against this PRNG weakness, attacks which could be conducted without direct access to the server (no shell or TCP/777 access). In the end NAI finally responded, finally released patches, and we moved on to other areas of research (ISIC, Comstock, etc).
Marcus writes: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 don't understand what that quip about hackers with keystroke-logging brains refers to, but that might just be my mental disability. I do agree that the crypto in any OTP personal authentication system has be merely appropriate for its function. That is, it has to be sufficient resistant to attack so that a Bad Guy can't effectively mimic its interaction with the authentication server, in a timely manner, to gain illicit access to protected resources.
No argument here. The one caveat being the old saying (paraphrased) that "the Good Guys have to get it right every time, but the Bad Guy only has to get lucky once". Reusable passwords were much easier to rant against, and attacks against OTP systems were much easier to calculate, back in the mid '90s when nearly everybody still used cleartext transport protocols, as successful exploitation of OTP by a true outsider *nearly always* requires logging a large number of challenges and responses... As it turns out, this wasn't the case with SNK. After I'd put all that effort into validating that SNK was "secure enough" for use by my self (and my paranoid friends and employers), just a few months later the ANSI X9.9 (the basis of SNK-004) standard was withdrawn. It seems that the X9 Committee learned that it was feasible to deduce (brute force) the shared secret key by observing just _two_ challenge/response pairs: http://www.x9.org/docs/TG24_1999.pdf Since then I've moved on to other authentication mechanisms, including S/Key for low-budget deployments, and the SecurID "fob" hardware token for larger commercial installations. Yes, the idea of token software on a multipurpose handheld device (Palm, Blackberry, cellphone, etc) is attractive. OTOH, there is much to be said for the benefits of a "sealed device", a single purpose "black box", the only interface to the outside world being a LCD and perhaps a few buttons to key in the PIN, challenge, destruct code, etc. While there are a number of theoretical attacks against hardware tokens, even the non-destructive approaches require physical access to the token for an extended period of time. Also, a successful attack only reveals the seed value for that one token. Speaking of theoretical attacks, I am currently working on demonstrating one such "theoretical" attack against the non-AES SecurID hardware token. Hopefully this time around the vendor will be more responsive. Kevin Kadow _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Re: Hardware tokens for remote access authentication, (continued)
- 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)
- Message not available
- RE: Hardware tokens for remote access authentication Marcus J. Ranum (Jul 13)