...is probably moot in this instance. The algorithm RSA uses, although proprietary, had already been previously reverse engineered.

The main concern is with the seed records. RSA seeds each token with a unique code, and then provides a record of it to be installed on the authentication server. By tying the seed record to the token serial #, the server knows the six-digit code being displayed at any given time.

The problem is that RSA retains these seed records, unless you request in writing that they destroy them. The fear is that the attackers may have acquired the seed record/serial # combinations. This would be bad, but for someone to utilize it, they would need to know the serial # and PIN number of the token in question, and they would also need to know the code currently be displayed for time synch. This would only be useful in a specifically targeted or possibly phishing type of attack.

Another concern I've seen raised is that with access to the seed records, an attacker could discern the specific record belonging to a token by sampling a number of passcodes/time-offset combinations and comparing them to the seed records applied to the algorithm to find a matching combination. Not so sure how effective or possible this would really be though. Even determining the seed key/serial # combo through sniffing traffic would still require knowledge of the PIN number.

A third concern is that someone may have accessed internal data/communications outlining known flaws in the implementation that could then be exploited. This one actually wouldn't surprise me compared to the other two, I'd really be stunned (and disappointed) to find the seed records were compromised on a machine that wasn't severely locked down and protected with an air-gap from any corporate network.

RSA's silence on this is deafening. Due to the design of their tokens, customers don't have the ability to simply generate new seeds or codes. If the data breach compromises the integrity of the currently deployed tokens (some 40M of them) and RSA can't isolate exactly which tokens may be impacted, they could be looking at a full-blown recall campaign. This doesn't even address the challenges of re-engineering to address any existing flaws or exploits, or the damage to their brand or the effort to rebuild customer trust.