two-factor authentication problems

[Ed Gerck]

Current solutions for two-factor authentication may be weaker than they
seem. Let me present two cases, including SecurID, for comments.

1. First case, without a clock, take a look at:
  http://www.ietf.org/internet-drafts/draft-mraihi-oath-hmac-otp-02.txt

Because the algorithm MUST be sequence or counter-based, poor
transmission can cause repeated failures to resynch. Also, someone
could get your token and quickly generate dozens of numbers without
you knowing it -- when you use the token later on, your new number is
not accepted and could fall outside the resynch window (even for two
numbers in sequence).

The worse part, however, is that the server side can always fake your
authentication using a third-party because the server side can
always calculate ahead and generate "your next number" for that
third-party to enter -- the same number that you would get from your
token. So, if someone breaks into your file using "your" number --
who is responsible? The server side can always deny foul play.

2. SecurID:
The last comment above applies. The server side always know what
numbers your token should generate now and in for days in the
future (clock drift included) -- and that's how they are recognized.
So, again, if someone breaks into your file using "your" number --
who is responsible?

Cheers,
Ed Gerck

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com