PayPal offering a hardware security token

[unixronin]

This is an interesting-looking gadget from PayPal: a hardware security token that you carry around with you on your keyring.

If, as the page says, the device generates a six-digit code "about every 30 seconds", then it can be expected to take "about" a year to exhaust all possible codes and start over. (If it generated a new code exactly every 30 seconds, and did not re-use any code until all codes had been used, it would exhaust the one million available codes in 347.222 days.)  On the face of it, this looks like pretty good odds.

However, the algorithm must necessarily be deterministic, or it wouldn't work.  And if it's deterministic, and someone can learn (disassemble, reverse-engineer, whatever) the algorithm, and can get (sniff or shoulder-surf, for example) any single code that you used and when it was used, they may possibly (depending on the algorithm) be able to determine what code your token will generate at any specified time in the future, unless each token has some kind of unique-per-token salt.  The "frequently asked questions" page does appear to imply that such a per-token key or salt exists.

Discuss.

Comments

[otherbill.livejournal.com]

If this is related to other similar security schemes, the salts are indeed unique per token.

I have a VPN keyfob that generates six-digit numbers; it allows me to connect remotely across <NewCompany>'s corporate firewall. Years ago, I had a similar credit-card sized device at <OldCompany>, until they migrated to SoftID, which did all of it in software.

This technology's been around for at least a decade. Granted, you follow this stuff much more than I do, but I think it's safe.

(Then again, doesn't the existence of this imply that PayPal doesn't consider https: secure enough?)

[ilcylic.livejournal.com]

Longer than that; as a (high school) student intern I had such a cc sized device in my wallet, erm, 14 years ago, in relation to $federal_scientific_laboratory, before my political evolution made such a job untenable.

Though, admittedly, at the time, my knowledge of cryptography was less than it is now, so I didn't properly evaluate it.

[unixronin.livejournal.com]

(Then again, doesn't the existence of this imply that PayPal doesn't consider https: secure enough?)

That is an interesting inference, isn't it...?

[lisa-marli.livejournal.com]

Cute, but I'd probably lose it. I think I'll just depend on doing what I can to keep my computers secure, rarely use computers that aren't mine and other security stuff.
But I can see where someone who uses computer cafes, school computers and other public computers might like to have that. Someone could run some sort of key cap and use that to steal logins and passwords. This way the password changes each time you log in. And being real portable, like they say, you can keep it on your key chain, it really lends itself to protection in those places.

[gdmusumeci.livejournal.com]

This sounds exactly like a SecurID (http://www.rsa.com/node.aspx?id=1156) token. I've used them at a few different companies now -- the technology works very well, although the keys have to be guarded strictly.

[unixronin.livejournal.com]

Yeah, the similarity struck me immediately.

[ilcylic.livejournal.com]

If it's not open source, it's crap.

----

Seriously, though, if it can't withstand peer review, fuck it.

[robbat2.livejournal.com]

I'd put money on units being branded SecurID units.

In the past, one of the earlier generations of SecurID units weren't as good as they are now, but RSA learnt the hard way about it.

Your assumption that the 6 digits don't repeat is a misunderstanding in assessing their security.

I had a trial kit that I picked up off a friend, and since I got it for nothing, I could actually go to the fully extend of hacking away at it.
The trial box ships with the server application (which only runs on Windows and Solaris) on 1 CD, plus a CD-R with the actual secret data relevant to the fob units that you have been shipped. In my case, it was 5 fob units.

The secret data is presented as follows:
digitally signed XML file, provable that it came from RSA, and hasn't been tampered with. The key fields in here are 32-bit integer of the fob serial number, and then a 128-bit hunk of random data. It also contains timestamps of fob birth and death dates, an algorithm number, how many digits are displayed on the fob, small-medium-large accuracy windows, and if the fob has a PIN/keypad.

The unit takes a 64-bit current time, the 128-bit random seed, the 32-bit serial number, and 32-bits of padding. Pass this 256 bits of data into AES256 in ECB mode, and then use some propitetary algorithm to select which N digits (my test samples were 8-digit) to display.

RSA has some patents on how they match time between the server and the fob units and keep track of time drift per fob. I'd imagine it being some variation on searching inside the accuracy windows, and remembering how far the unit was off last time. In my data, the windows were 60,120,600 respectively.

The fobs are good for one purpose really - preventing long-term replay attacks. The attacker basically has to be able to use what he captures as soon as possible, because the sequences wouldn't match otherwise.

Of course this is all moot if he steals the fob and social-engineers the other authentication information out of it's owner.

[robbat2.livejournal.com]

oh, and their official software won't load XML files that haven't been signed by RSA either.
plus I'd expect that they have some of tamper-proofing in the keys themselves to avoid anybody stealing the internal seed data (but the serial number is printed on the back of each fob).

[unixronin.livejournal.com]

Your assumption that the 6 digits don't repeat is a misunderstanding in assessing their security.

Oh, I'm not assuming that it necessarily has a no-repeat rule. It's simply that the assumption turns out to yield a relatively simple practical illustration of the size of its "keyspace": Approximately one year for it to exhaust its keyspace, assuming no repeats.

The fobs are good for one purpose really - preventing long-term replay attacks. The attacker basically has to be able to use what he captures as soon as possible, because the sequences wouldn't match otherwise.

Precisely. And since the device changes its key approximately once every 30 seconds, it's reasonable to assume that any possible attacker has at most something on the order of 30 seconds to one minute to attempt a replay attack.

Of course this is all moot if he steals the fob and social-engineers the other authentication information out of it's owner.

Of course. But even in that case, it's certainly no less secure than the userID and password alone.

[greyman.livejournal.com]

<lj user="robbat2" 's explanation is correct and coherent. I don't know the specifics regarding key sizes and random blocks, but the numbers listed would work. Relatively large keys compared to the 20 bits of information you do get per 30 seconds, plus a good one-way hash to generate those 20 bits, would make it difficult to determine where you were in the full (large) sequence. Without knowing that you wouldn't be able to predict with confidence a large series of output values. The synchronization doesn't just look back and forward N windows, but it also asks you for the next number generated. So even if it gives you a false positive on the first number it's unlikely to match the second.

[ithildae.livejournal.com]

I used a secure ID fob about a decade back that sounds about exactly like this product. The algorithm is deterministic, but each device had it's own "special salt" so that there was not one master algorithm. We needed to install hardware at the server to match the fobs. While I believe that nothing in the wild is truly secure, this come pretty close.