[SGVLUG] Secure "one time" passwords -- oh really?

[Emerson, Tom (*IC)]

OK, now that I've got John busy reconfiguring his security system, I've got a question for the rest of you: how "secure" do you think the "safeword" password token generator is?

[trick question, I know, because safeword was bought by McAfee]

On the surface, I'm not convinced (as you might guess, I've recently been assigned one of these)  There are two models they talk about - one that you need only "push a button" to get the (next) "one-time" password token, and another where you need to enter a "pin" and it will generate the next token for that PIN.  (and a third option is proprietary software loaded onto your system or blackberry/phone)  In some of the documents, they mention that the tokens can be either "time based" or "event based".  (and I presume "event" means "token generated", since I don't see any way the fob you carry and back-end "validating" server would otherwise agree on what an "event" is)

The card generates what appears to be a 6 (hexadecimal) digit value  (i.e., 3 bytes)  I have the one where you enter a 4 (decimal) digit PIN (and per related documents I've received, if you get the pin "wrong", it generates an invalid token)  Just breaking it down on that aspect alone, the token generator can generate up to 2^24 tokens of which (for the PIN based ones) 1 in 10000 are legit -- someone please check my math, because I only come up with 1677 valid passwords for the life of the token generator! (2^24 / 10000)  heavy use of the device (10 validations/day) would kill that in less than half a year!  (though I suspect "typical use" might be twice a day/weekdays only/50 work-weeks per year, or about 3 years of useful life [2 * 5 * 50 = 500 uses/year])

Then there is the challenge of tracking "use" of the tokens - I can think of two methods (and I have an idea as to which was used)  The "validating" server can generate every valid token and store that as some form of list, "crossing off" each token as it is used [more realistically, a 16-million-bit bitmask with "1"'s set for each valid token; as they are used, they get reset to 0] OR you prepare a database with 1677 blank entries, filling in each one "as used" (and doing a search each time a token is presented to see if it's been used)  Either would work because the entire range of "valid" tokens pretty much "has to be" generated programmatically (and possibly modulated based on the time-and-date that the token is generated, but this "complication" only makes it more difficult for a "human" -- see below)

Since the guy that was activating my card indicated "this next step takes some time", I imagine the list is pre-generated  (if you use a "bitmask" it would only need to be 2 megabytes long -- years ago, that would be a showstopper, but in today's age of terabyte drives...)  I don't know offhand if my card is also time-based (but that's easy to test...)

In any case, I can see that the "push for a new token" card wouldn't be terribly secure (if it is only "event" based) as someone could copy a block of tokens should they get ahold of the card (and since there is no indication of how many tokens have been generated, the user wouldn't necessarily know that he'd been compromised)  The pin-based one is a little better as a "random guess" only has a 1-in-10000 chance of getting the correct PIN (or to put it another way, for an attacker to store off potential tokens for later use, they would have to generate/store 9999 other tokens as well)  Of course, should the PIN be compromised, the device is no more secure than the single-push version  [though, a thought occurs -- if the "PIN" that you enter is used in some way to modify the token generated, and that "method" becomes known, it would be trivial to convert any given result to what it would be with a different PIN - the attacker need only store tokens generated for PIN 0000...]

The "time based" ones are, again, only marginally more secure since (I imagine...) there has to be some set algorithm to convert a "good" token to "good at /this/ moment" token, and if that's the case, chances are pretty good this algorithm can be reversed, and again, someone could extract any number of tokens and "adjust" for the time of day (by first back-converting to the base token, then at the time you wish to break in, convert any base value token to a current-time version...)

Oh well, food for thought for the weekend... Gotta go...