OK. I sneak into a store at night, install a little dongle between the reader and the phone line (I'm using the credit card readers just as an example). I come back the next night, and I have all of the patterns sent out to be validated that day! Once I have the patterns, I don't need the reader, the fob or any physical item anymore. </p><p> One "obvious" solution to this is to encrypt the pattern at the device before it is sent, but now we're back into the standard encryption world, and we know that nothing is perfect there. </p><p> OK, so we change the pattern based on the date and time with a "protected" algorithm. Like that can't be solved. </p><p> Well, then we'll use a system like the "SecureID" cards with each credit card unit including the random/automaticly generated token as part of the encryption effort. Well that would be a little more complex. </p><p> But in the end, all of these solutions can be applied to the current barcode read from credit cards before it is sent over the phone lines today. The use of a 3D number/key generator, which is really what this is, won't change that. </p><p> P.S. Don't ask me how this could be used at Websites.... Pardon me, while I send this huge bit representation of your 3D fob over this dinky 56Kb error prone phone line. Right....</p>
Slashdot Mirror
OK. I sneak into a store at night, install a little dongle between the reader and the phone line (I'm using the credit card readers just as an example). I come back the next night, and I have all of the patterns sent out to be validated that day! Once I have the patterns, I don't need the reader, the fob or any physical item anymore.
</p><p>
One "obvious" solution to this is to encrypt the pattern at the device before it is sent, but now we're back into the standard encryption world, and we know that nothing is perfect there.
</p><p>
OK, so we change the pattern based on the date and time with a "protected" algorithm. Like that can't be solved.
</p><p>
Well, then we'll use a system like the "SecureID" cards with each credit card unit including the random/automaticly generated token as part of the encryption effort. Well that would be a little more complex.
</p><p>
But in the end, all of these solutions can be applied to the current barcode read from credit cards before it is sent over the phone lines today. The use of a 3D number/key generator, which is really what this is, won't change that.
</p><p>
P.S. Don't ask me how this could be used at Websites.... Pardon me, while I send this huge bit representation of your 3D fob over this dinky 56Kb error prone phone line. Right....</p>