So yesterday, RSA, a security division within EMC and the folks responsible for SecurID, one of the most popular forms of two-factor authentication, announced that they’d been hacked.

What does this mean? Well, we don’t have many details, but the most troubling bit is that apparently the attackers acquired information “specifically related to RSA’s SecurID two-factor authentication products.” In particular, that “this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack."

This is quite troubling. SecurID is used by over 25,000 customers, with an estimated 40 million physical tokens in circulation (in addition to 250 million software-based tokens). Many of these are used for secure authentication to corporate websites and email, and they’ve seen increasing use in online banking. A “reduction in effectiveness” could have very serious, and wide-ranging, consequences.

So what exactly could the attackers have gotten away with? First, a quick review of how SecurID tokens work.

At its core, SecurID is a cryptographic algorithm that produces random numbers in a pre-determined sequence. This sequence is known to an authentication server, and used to validate that the person logging in has the token in their possession. To keep the tokens unique, each is pre-loaded with a seed that initializes the sequence for each token. The resulting 6-digit numbers, or “tokencodes,” are therefore produced in a sequence specific and unique to each token.

This seed is typically 128-bits in length, so there are approximately 500 gagillion (a really really big number) potential sequences that any individual token could produce. Far too many for an attacker to have any practical chance at a brute-force attack.

Where the attack gets scary is if the seeds have been revealed to a third party. While there are many good reasons why RSA should not keep copies of tokens' initial seeds, there are also some reasons why they might. Ultimately, I believe we’re facing four attack scenarios:

  1. Attackers get a list of seeds and token serial numbers. Then if they are able to acquire the serial number from a target’s token, they can replicate the token in software and use that to impersonate the target.
  2. Attackers get a list of seeds, and the corporations to which they’ve been assigned. This makes the attack a little tougher, but having only several thousand seeds to test is enormously better than having a 128-bit seed to test.
  3. Attackers get a list of all seeds issued thus far. Instead of having several thousand potential seeds to test, they have a few hundred million. Still much better than searching a 128-bit keyspace.
  4. Attackers find some weakness in the method used to generate seeds in the first place. Perhaps it uses a weak random number algorithm. Or maybe there’s a “master seed” that generates new seeds in sequence, just like the tokens itself.

(There’s actually a fifth scenario – internal documentation revealing a known weakness in the algorithm that allows an attacker to derive the key simply by observing multiple tokencodes. Without knowing how their tokencode algorithm works, we can’t know if this is even possible, but it seems exceedingly remote. At least we hope so.)

In all scenarios, the attacker will also need to observe at least one, probably two, tokencodes from the target in order to synchronize their sequence with the target’s token. They’ll need to observe a login anyway, just to get the target’s PIN (which is usually prepended to the tokencode at login).

So what’s the risk to your enterprise? Until we know more, there’s no way to say. If any of the first three scenarios come into play, then the risk for some high-value targets may be reasonably high. Any attacker who can monitor login attempts, perhaps through something as simple as a fake login page, will be able in short order to duplicate the target’s token and authenticate as them. The only way to mitigate that would be to replace all the tokens in circulation.

If the fourth (or worse, fifth) scenario is true, then there’s a much more significant risk to the RSA/SecurID system as a whole. It would compromise not only issued tokens, but every replacement token in stock. It breaks the system, until the seed-generation process, or even the token algorithm itself, can be changed, and new tokens produced.

Ideally, though, RSA won’t have any seeds stored, nor will there be any weakness in the methods used to generate those seeds. If that’s the case, then the worst that could happen is that the token algorithm itself may be leaked. Perhaps study of the algorithm could reveal weaknesses….but that’s a much longer term concern.

There is, however, one last, very likely scenario: Just as with any big-news item, this compromise could open the doors for any of several phishing scenarios. Attackers could certainly capitalize on the uncertainty of what’s happened to trick users into revealing information that would enable a reset of their credentials, regardless of whether they’re even using the SecurID system in the first place. In the long run, this attack could affect far more than just RSA’s customers.

(view Archived Comments)