Re: Hardware tokens for remote access authentication

[kadokev () soak msg net]

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