Re: Username password VS hardware token plus PIN

[David Lang <david.lang () digitalinsight com>]

On Thu, 24 Feb 2005, Marcus J. Ranum wrote:

> David Lang wrote:
> > IIRC the vunerability of the ols SNK004 format tokens was that if you received enough challange/response pairs 
> > (potentially as few as two) you could brute-force the DES encryption key and duplicate the token.
>
> At the time, brute-forcing DES was not considered an option
> by most people.

at the time they were introduced it definantly was not an issue, nowdays 
it can be done, but is not trivial to do. my comment was in part a request 
for confirmation that the vunerability that was discovered with that type 
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 
types in an 8 digit response (either 8 digits of decimal or 8 digits of 
hex)

in the old days the argument was that even if the attacker harvests 
challange-response pairs the fact that at most 32 bits of the 64 bit 
response is available would mean that the number of potential keys that 
could convert that challange to that response was too large to be 
searchable in a practical time.

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) and a couple 
challange-response pairs the attacker could enumerate two sets of 
possible keys

set 1. every key that could convert the first challange to the first 
response,

set 2. every key that could convert the second challange to the second 
response

and then look for every key that is in both sets, and in some cases this 
would result in a valid key with as few as two challange-response pairs


my comment above was intended to be that if this is the new attack 
procedure that 'makes these worthless' then I woudl say that it weakened 
them, but not nessasarily to the point of them being worthless. I wouldn't 
be as happy trusting them to secure cleartext communication over the 
Internet (or other area where the risk of the bad guy sniffing thngs is 
considered high), but if used in an otherwise encrypted session they still 
have significant value

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. :-)

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.

in a situation where you only have a single authentication server you can 
try to cope with this by having the server record how far off the token is 
and only allow a narrow drift from that for the enxt authentication.

however if a token is used infrequently (i.e. emergancy access that's 
tested once a year) the drift can still be substantial.

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 (and 
frankly I would much rather deal with the administrative cost of putting 
the same token in 5 servers in 5 states then to have each of the users 
carry around 5 tokens and have to figure out the right one to use for this 
connection) you have to open up the time window again becouse they may not 
have used this particular authentication server in quite a while)

Add to this the issue of sending the pin along with the response rather 
then useing the pin to activate the token and it just makes me less happy 
with them.

David Lang

 -- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards