Re: [fw-wiz] Username password VS hardware token plus PIN

From: Marcus J. Ranum (mjr_at_ranum.com)
Date: 02/25/05

  • Next message: Mark Sargent: "[fw-wiz] NOKIA CC500 Password Recovery" 
    To: David Lang <david.lang@digitalinsight.com>
Date: Fri, 25 Feb 2005 17:23:14 -0500

    David Lang wrote:
    >On Thu, 24 Feb 2005, Marcus J. Ranum wrote:
    >these tokens take a 6-8 digit challange, encrypt it with DES, and the user types in an 8 digit response (either 8 digits of decimal or 8 digits of hex)

    Yes, and the DES output is "folded" down into something readable, so there
    is a process of truncation. Even using 56-bit DES the strength of the token
    is not 56-bit. But that hardly matters, really, since if you have a key-guess
    that yields a likely candidate response, the odds that you'll get a collision
    (wrong key, right response) are equally low. If you have 2 challenge/response
    pairs it's pretty much zero.

    >my understanding of the 'fatal weakness' is that given the increase in the ability to crack DES (what is it now, a $1m cluster can average a day to crack a single message or something like that)

    Yeah.. Even in those days (early 1990's) it was believed that certain
    government agencies had DES cracking hardware. I'm sure they spent
    more than $1m on it.

    But this reveals a bogus aspect of crypto think: who'd bother building a
    $1m machine if they could get my key for a whole lot less? I mean, if
    you offered me $100,000 for every password and key I know, I think
    we might have a deal. :) Want to see if they've changed the root password
    on whitehouse.gov? (Actually, I'm sure they have; they decommissioned
    the old system and had a bunch of beltway bandits put up something else
    that promptly got hacked...) Key purchase attacks are always fairly
    cost effective in the small. You only need the DES cracker if you are going
    after large numbers of keys or going against a system where the keys
    are automatically updated periodically (ahem).

    >so the first question is am I properly understanding the vunerability, the second question is how far off base does everyone consider me to be. :-)

    You're on base but the practical attacks against those systems used
    to be much more cost-effective. Consider that if you are able to collect
    a challenge/response pair or two then you're in the transaction path.
    Why not just steal the data stream after the login phase? It's mostly
    trivial and it's a lot easier than cracking a key.

    >personally I have never been happy with the idea of time-based tokens.
    >
    >while I understand that in theory every machine has the same time, the reality is that ntp configuration gets botched and machines revert to their local clocks which then drift (and the clocks inside the tokens drift as well).
    >
    >the solution seems to be that as long as the clock is 'close enough' the server will accept it. unfortunantly this 'close enough' now means that it's not a one-time key, but a key that can be used within a (hopefully narrow) window of time.

    Security Dynamics patent covers clock skewing - it's their "special sauce"
    (even though it's probably obvious to a skilled practitioner). Basically what
    you do is since the token's clock may diverge from the server's the server
    keeps track of the last time the token successfully authenticated. The
    next time it authenticates, it can "window" around the correct value and
    determine how much the token is skewed (forward or backwards in time)
    and how fast it drifts by how far it is out of window. Then you just store
    the clock drift factor for each token, and you can now scale the window
    forward or backward and open it or narrow it depending on how long it's
    been since you saw that particular token. Not rocket science, but it works
    just fine for all intents and purposes. An attacker would have to crack
    the DES key and know the stored clock drift for the card (which you could
    compute the same way the server does if you have the key)

    >also if you need to have multiple authentication servers that aren't synced directly to each other where you want to use the same token

    They are; they have to be. Otherwise someone who steals a code can
    use it to log in through a different server than the authorized user.

    These are all theoretical attacks and, in my book, are fairly pointless.
    I'd love it if someone came forward with a real-life case where a
    token was attacked cryptographically in a practical application.
    I just don't think anyone'd bother. It'd make much more sense to
    compromise the user's endpoint and steal their session that
    way, or steal their session in transit if it's over IP.

    mjr.

    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

  • Next message: Mark Sargent: "[fw-wiz] NOKIA CC500 Password Recovery"

    Relevant Pages

    • Re: [fw-wiz] Username password VS hardware token plus PIN
      ... of token still required a couple brute force attacks against DES. ... these tokens take a 6-8 digit challange, encrypt it with DES, and the user ... personally I have never been happy with the idea of time-based tokens. ... in a situation where you only have a single authentication server you can ...
      (Firewall-Wizards)
    • Re: (OT)(Blog) You Know That Sinking Feeling ...
      ... <fx: starts clock ...> ... des | 'what does it matter what he posts?' ... end the 'occupation': http://minilien.fr/a0k8xe ...
      (uk.rec.motorcycles)