Twitter was abuzz yesterday and today on the RSA hack. From what I could infer, worst case, the SecurID seed files may have been disclosed in a hack. A quick primer on SecurID is needed to see why this is and isn't an issue.
Token: hardware or software device that displays a token code
Token code: pseudo-random numbers displayed on a RSA token. Can change at different frequencies (30 seconds, 1 minute, etc.)
PIN: user's secret code. Can be numeric or alphanumeric, depending upon configuration.
Passcode: PIN+tokencode
RSA SecurID uses soft and hard tokens. I'll focus on the hard tokens for this. The tokens as I understand them are PRNG. Each token has a random seed to start its PRNG. The date and time the token was started with the seed, along with the seed itself, and the token's serial number, are sent to the customer. The customer then loads this seed file into the Primary SecurID server at the customer's premise. The Primary then can guess the current tokencode displayed on the token by inputting this seed into the PRNG. Clock-skew aside, the code computed by the Primary should be the code displayed on the token.
As the customer adds users to the system, the customer associates a token to some user ID. This association should never be known outside of the Primary, secondaries, and backups. Usually front-end authenticators communicate to the Primary, via RADIUS, RSA's own proprietary protocol, or other supported methods. So, assuming an attacker has obtained the seed files, token serial numbers, and the organization that received the seed files, they'll still need to know the user ID association, the user's PIN, and the relative clock skew of the token.
The RSA hack though only buys the attacker the first part of the equation (seed, token, date). The attacker would still need to perform a targeted attack against a user / org to obtain the token <=> user mapping AND the user's PIN. The Primary has mitigating controls to lock out a user after some amount of failed login attempts. But, let's hand-wave and say the attacker has somehow obtained the token <=> user account mapping and the user's PIN, which could be the user's domain password in some setups. They still need to generate the tokencode on the token.
Getting back to clock skew, since physical tokens are physical, its clock will skew over time. The Primary stores this skew and allows a range. The more the token is used, the better the Primary will know its skew. If the token is too far out of skew, the Primary will log an event and require the to user enter the subsequent token code. If the token continues go to out of skew, the Primary will disallow its use and require the user to obtain a new token. An attacker starting a blind attack will not know the token's relative skew. So, even if this is a targeted attack against an individual, where the attacker knows the seed, token serial number, user ID, and user's PIN, there's still even a chance that the attacker will not be able to authenticate because of the token's clock skew will be too far off.
With all of this, there is some worry. If you're in a small organization with say 20 people, it'll be easier for a knowledgeable attacker to associate some random token to some user account. RSA should also do the right thing and allow organizations to replace their tokens if the organizations deem it necessary, free of charge. A large organization will probably not do this, though. It's costly to do mass upgrades of tokens. For example, each token has an expiration date of usually 2-3 years. After this time, an organization will have to phase in a token replacement process. Support calls go up. People get locked out. It's a pain. But, if you're a small shop, it's easier to manage this. And, if you're a small shop, you're at a higher risk.
In the end, it's about your organization's relative risk. I just don't see a big story here.
(Updated 11:37 EDT: noticed I wrote PIN/passcode before. This was incorrect. Changed to PIN.)
0 comments:
Post a Comment