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.
no subject
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?)
no subject
Though, admittedly, at the time, my knowledge of cryptography was less than it is now, so I didn't properly evaluate it.
no subject
That is an interesting inference, isn't it...?
no subject
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.
no subject
no subject
no subject
----
Seriously, though, if it can't withstand peer review, fuck it.
no subject
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.
no subject
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).
no subject
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. But even in that case, it's certainly no less secure than the userID and password alone.
no subject
no subject