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

[Emerson, Tom (*IC)]

> -----Original Message----- Of Charles Wyble
> Emerson, Tom (*IC) wrote:
>
> > I've got a question for the rest of you: how "secure" do
> > you think the "safeword" password token generator is?
...
> > On the surface, I'm not convinced ...
> > The card generates what appears to be a 6 (hexadecimal) digit value
> > (i.e., 3 bytes)  ...

OK, a little more thought on this on the drive home, and I did envision a method to make this more secure, or at least drastically reduce the chance of back-computing the rest of the "valid" tokens given a handful of "used" tokens.

If indeed the actual "token" is 3 bytes, expressed as a 6-hex-digit value, there are potentially 2^24 tokens (16 million)  However, they have to be divided into "valid" and "invalid" groups  (otherwise that would imply that at the start, ALL tokens are valid, which probably isn't terribly secure...)

Actually storing 16 million 3-byte values, however, can be accomplished in 48 megabytes (3 * 16), which is well within the scope of modern FLASH memories (though it may have been a stretch 5 or 10 years ago...)  [note also that pushing this to a 4-byte value bumps this up to a couple of gigabytes, which is "just now" economically viable]

If you were to take the entire series of numbers from 000000 thru ffffff and randomly assign them to two or more "groups", depending on the randomness of the method chosen, it should be virtually impossible to state with any authority that a given value falls within any particular group.  (in other words, the "list" of tokens in any given subset are not algorithmically assigned, hence impossible to "back-compute" based on the knowledge of one or more previously-accepted tokens)

Once the assignment of tokens to lists are done, you copy the lists to both the device and the server, then choose any arbitrary list as the one that will be considered to contain "valid" passwords.  (or, for the case of the PIN based device, the PIN would select the list -- as an advantage, you could then re-use the same device several times without reloading by simply changing which PIN/list is to be considered "valid")

Of course, if there are only two lists, chances are pretty good (well, ok, "50-50") that any arbitrary value is "valid" [decreasing over time as passwords get used]  OTOH, a 4-digit PIN lends itself to 10,000 such "lists", and a 1-in-10000 chance of an arbitrary number being considered "valid" is probably acceptable for this purpose.  (if my thought/example of "changing the PIN without reloading" holds any water, the only cost would be that the number of "known bad passwords" increases over time, so the second use of the device without a reload would reduce the chances to 1-in-9999 -- of course, this presumes the "attacker" had some method of recording used passwords and therefore wouldn't select those again...)

Of course, the vulnerable points are the server [presumably under lock and key, perhaps even armed guards on station...] and the FOB itself [umm, can you say "weakest link"?]  You need to ensure that an attacker couldn't "crack open the case" and read the FLASH memory  (or else ensure that even if someone were to read the contents of memory, determining which are the "good bits" vs. "bad bits" is computationally difficult, but not so difficult that a button-cell-powered CPU can't retrieve and display "the next" valid number in a timely manner, say 250 milliseconds...)

> >
> > Oh well, food for thought for the weekend... Gotta go...
> >
>
> Thanks for the post.

You're quite welcome :)  I hope my follow-on was equally interesting

> I don't do a lot of security work anymore, as I got tired of the very
> long audit sessions and stating my name/position/responsibilities etc
> for the permanent record, ...

>   So I hope I answered your questions. Perhaps someone can do a
> presentation on two factor VPN authentication with open
> source software at SGVLUG?

[hint hint -- YES, that would be a GREAT topic to see...]