Comment Re:Why the banks support a standard 2 factor syste (Score 4, Informative) 71
Quite a few of the 'security' arrangements in financial areas make it abundantly clear that they suck because you don't really matter (this goes triple or worse for anything involving credit reports).
That said, RSA-fobs(or house-branded devices based on the same system) aren't actually something that would be trivial to share between organizations.
The RSA fob works because it is initialized with a given seed value at a given time. Every minute it performs a hash operation that provides enough output for the on screen numeric sequence along with the input for the next hash operation(if memory serves, it is reasonably well established that it is either impossible or computationally impractical to derive the internal state from knowledge of the screen output alone, even if you have many samples).
In order to enroll a fob in your authentication system, your auth server needs to know the seed and the initialization time. It can then run N rounds of the algorithm(based on the amount of time between initialization time and current time) and determine what should be displayed on the screen(sometimes allowing for a few minutes of slip, depending on how accurate the RTCs are believed to be), If you want Company B to use Company A's token, either Company B needs to pass every auth request to Company A for processing, and accept the result, or Company A actually has to send Company B the seed an initialization time for your fob(an operation that opens up certain obvious security concerns).
The RSA fobs are pretty cute(if it weren't for the fact that RSA stores all the seed values and times, and managed to get them stolen at least once), in that they require absolutely no communication between the fob and the auth server, ever; but they do suffer from the weakness that the data needed to validate a fob are also the data sufficient to clone a fob, which makes sharing a single fob between multiple entities pretty awkward.
That said, RSA-fobs(or house-branded devices based on the same system) aren't actually something that would be trivial to share between organizations.
The RSA fob works because it is initialized with a given seed value at a given time. Every minute it performs a hash operation that provides enough output for the on screen numeric sequence along with the input for the next hash operation(if memory serves, it is reasonably well established that it is either impossible or computationally impractical to derive the internal state from knowledge of the screen output alone, even if you have many samples).
In order to enroll a fob in your authentication system, your auth server needs to know the seed and the initialization time. It can then run N rounds of the algorithm(based on the amount of time between initialization time and current time) and determine what should be displayed on the screen(sometimes allowing for a few minutes of slip, depending on how accurate the RTCs are believed to be), If you want Company B to use Company A's token, either Company B needs to pass every auth request to Company A for processing, and accept the result, or Company A actually has to send Company B the seed an initialization time for your fob(an operation that opens up certain obvious security concerns).
The RSA fobs are pretty cute(if it weren't for the fact that RSA stores all the seed values and times, and managed to get them stolen at least once), in that they require absolutely no communication between the fob and the auth server, ever; but they do suffer from the weakness that the data needed to validate a fob are also the data sufficient to clone a fob, which makes sharing a single fob between multiple entities pretty awkward.