Re: Username password VS hardware token plus PIN

["Marcus J. Ranum" <mjr () ranum com>]

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