I've programmed some for OTP devices. Vasco primarily, but some RSA too. Normally, the OTP algorithm takes two args... a "shared secret" (each customer has a different secret) and the exact date/time. All the fobs and the back-end server know/share the secret.
On the fob thingy, one calculation occurs. The fob can be physical or virtual. So you may have a physical key fob or a virtual software fob for your blackberry, iPhone, Droid, etc. They even work with dumb phones over SMS. Either way, the same calculation occurs. Again, it looks something like this:
So when you push the button on the fob (or just look at it if it's the always on type), it returns an OTP. On the server, the exact same calculation occurs except that it calculates a range of OTPs (in case the time on the fob has drifted... and this does indeed occur). A minute or so worth of calculations. The fob's OTP must fall into the server's calculated range, if not, the OTP will fail and the fob will need to be recalibrated (resync its clock).
So, if this story is true, then the list of customer shared secrets was stolen and whoever has them now knows that company X uses secret Y on their fobs. It's hard to believe that RSA actually had a list matching company names to shared secrets unencrypted. I'm not sure I believe that.
It doesn't matter if it was store unencrypted if they could capture the credentials used to decrypt it. It was previously disclosed that they managed to get credentials and administrator / root level access through large parts of RSA. Do you think that this level of acces would still be unable to access the database?
On the fob thingy, one calculation occurs. The fob can be physical or virtual. So you may have a physical key fob or a virtual software fob for your blackberry, iPhone, Droid, etc. They even work with dumb phones over SMS. Either way, the same calculation occurs. Again, it looks something like this:
const unsigned int OTP ( const string& shared_secret, const time& time_of_day ) { return OTP; }
So when you push the button on the fob (or just look at it if it's the always on type), it returns an OTP. On the server, the exact same calculation occurs except that it calculates a range of OTPs (in case the time on the fob has drifted... and this does indeed occur). A minute or so worth of calculations. The fob's OTP must fall into the server's calculated range, if not, the OTP will fail and the fob will need to be recalibrated (resync its clock).
So, if this story is true, then the list of customer shared secrets was stolen and whoever has them now knows that company X uses secret Y on their fobs. It's hard to believe that RSA actually had a list matching company names to shared secrets unencrypted. I'm not sure I believe that.