[fw-wiz] Re: Hardware tokens for remote access authentication

Date: 07/15/04

  • Next message: ArkanoiD: "Re: [fw-wiz] Hardware tokens for remote access authentication"
    To: firewall-wizards@honor.icsalabs.com
    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

    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:

    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

  • Next message: ArkanoiD: "Re: [fw-wiz] Hardware tokens for remote access authentication"

    Relevant Pages

    • Re: MSFT Bans insecure hashes - was"Passwords with Lan Manager (LM) under Windows"
      ... After I pointed out that "IPsec based auth" is not a basic netlogon ... authentication protocol like Kerberos, LM, NTLM and NTLMv2, you said I was ... based auth" to authenticate the request as opposed to LM, NTLM, or NTLMv2. ... Up to 75% of cyber attacks are launched on shopping carts, forms, ...
    • Re: Passwords - why hash?
      ... Authentication protocols like NetBIOS and Kerberos try to prevent sending ... additionally vulnerable to attacks on the encryption / decryption keys, ... One problem with symmetric encryption is that if you wanted to use it to ... Adding salt would help prevent pre-compiled hash "rainbow table" attacks. ...
    • Re: Remote Administrator 2.x: highly possible remote hole or back door
      ... >> using simple password authentication. ... > is observed in more than one of the attacks. ... However, if what you passed the daemon was an improperly-encoded string, it ... The client, which was just sending the query and then reading a single line ...
    • Re: ADVERT: Secure communications.
      ... What attacks could be applied to it? ... >> ciphertext were corrupted, after decryption the plaintext would differ ... Or would it be insecure for either privacy ... >> or authentication? ...