Become a fan of Slashdot on Facebook


Forgot your password?
Crime Security The Military IT Your Rights Online

RSA Admits SecurID Tokens Have Been Compromised 219

A few months ago, RSA Servers were hacked, and a few weeks ago Duped tokens were used to hack Lockheed-Martin. Well today Orome1 writes "RSA has finally admitted publicly that the March breach into its systems has resulted in the compromise of their SecurID two-factor authentication tokens. The admission comes in the wake of cyber intrusions into the networks of three US military contractors: Lockheed Martin, L-3 Communications and Northrop Grumman — one of them confirmed by the company, others hinted at by internal warnings and unusual domain name and password reset process."
This discussion has been archived. No new comments can be posted.

RSA Admits SecurID Tokens Have Been Compromised

Comments Filter:
  • Cyber intrusions (Score:4, Insightful)

    by ArAgost ( 853804 ) on Tuesday June 07, 2011 @08:52AM (#36361248) Homepage
    1992 called, they wanted the adjective “cyber” back.
  • Dear Customers... (Score:5, Insightful)

    by fuzzyfuzzyfungus ( 1223518 ) on Tuesday June 07, 2011 @08:58AM (#36361294) Journal
    Golly Shucks. As it turns out, maintaining a copy of the seed keys for devices we sold specifically as a high-security access control solution on our under-secured network might have been a less than totally good idea... Well, lessons learned, eh?
  • by asifyoucare ( 302582 ) on Tuesday June 07, 2011 @09:00AM (#36361308)

    RSA betrayed their customers, only admitting to the extent of the hack after it was obvious to all that the tokens were compromised. They're untrustworthy, yet they're in a business where trust is paramount, and I'll be recommending to the company I work for that we don't deal with them again. We are a current customer, and we're now scrambling to envisage and generate reports from authentication logs for exceptions that might indicate we're being attacked or have been successfully attacked in the past.

    If they actually cared about providing security to their customers instead of covering their own asses they'd have kept their customers fully informed, but they didn't. If they weren't covering their asses and actually didn't have the logging around their crown jewels to let them know what had happened, well that's even worse.

    They're now on my shit list, along with Verisign and Sony, of companies I never want to do business with again.

  • by Anonymous Coward on Tuesday June 07, 2011 @09:18AM (#36361452)

    I think we're all assuming (for the most part) that the attack was over a network. If the keys were physically stolen from an offline box, then that's a different matter. If they had their high-security seed keys--as GP refers to them--accessible remotely in any manner, that was probably an avoidable mistake.

  • by fuzzyfuzzyfungus ( 1223518 ) on Tuesday June 07, 2011 @09:19AM (#36361474) Journal
    My main issue was with retaining the seed keys in any network accessible location.

    Those things should have been deleted upon transfer to the customer or(if so requested) stored on archival media in a vault somewhere unless needed by the customer for recovery purposes.

    My point isn't "Ha Ha, their network guys fucked up, I could have done better!" My point is "for something as interesting as the seeds you would find useful in compromising a laundry-list of high-profile, high-security targets, basically no configuration would be sufficiently secure, and storing them in an insufficiently secure manner is hugely irresponsible.

    After the the tokens were seeded, there was no further need for RSA to have them anywhere that they could be accessed electronically.
  • by thijsh ( 910751 ) on Tuesday June 07, 2011 @09:24AM (#36361498) Journal
    For master encryption keys anything other than offline physically secure storage is a risk that is too high... The extra hassle of having a guy physically go to the storage when new certificates need to be signed is what you pay the security premium for right? This is not about discount SSL certificates that need to be sent with an automated process, no need at all to hook the machines to the internet... under-secured or super-duper-unbreakable-secure(tm) does not matter, just don't.
  • by fuzzyfuzzyfungus ( 1223518 ) on Tuesday June 07, 2011 @09:25AM (#36361502) Journal
    RSA's customers certainly need to have a copy of their tokens' seed keys on their authentication server; but RSA doesn't need a copy of their customers' seed keys...
  • by fuzzyfuzzyfungus ( 1223518 ) on Tuesday June 07, 2011 @09:27AM (#36361538) Journal
    Dear customers who don't matter,

    We are committed to providing you with a customer experience commesurate with what we can get away with. XOXOXO,
  • two factor? (Score:5, Insightful)

    by vlm ( 69642 ) on Tuesday June 07, 2011 @09:40AM (#36361690)

    All I can find is the usual journalistic garbage, some fear mongering here and there, some harsh comments about RSA, some financial "news" commentary. No real information.

    Can anyone on /. with technical knowledge, comment on the hack breaking the entire system (essentially, rooting the auth system) or is it just breaking one of the two factors, that being able to predict the "random" number generation of the keyfobs, so I'm down to merely having a pretty good "one factor"?

    Also is the protocol poorly enough designed that the attackers don't need to know anything about the keyfobs, or rephrased, does keeping the serial number info etc about individuals keyfobs secret prevent the break?

  • by vlm ( 69642 ) on Tuesday June 07, 2011 @09:50AM (#36361806)

    RSA's customers certainly need to have a copy of their tokens' seed keys on their authentication server; but RSA doesn't need a copy of their customers' seed keys...

    Unfortunately, I imagine they do need the copy: otherwise how do they make sure they never issue duplicates to different customers?

    LOL that one was funny, and some PHB requirement like that is probably the cause of the whole problem. Like intro to crypto 101 problem funny. To the noobs out there, the solution involves storing the hash of the existing keys instead of the keys themselves. Supposedly, can't turn a hash back into a key, but if the hash of your new key matches a pre-existing hash, then its a dupe, make another and try again.

    That's only needed if it's required to prove there's no dupes... realistically, if you have a 1024 bit key and 16 bits worth of customers, the odds of a collision, which wouldn't matter anyway, are 1 in 2 ** (1008) or in other words quite unlikely.

  • by fuzzyfuzzyfungus ( 1223518 ) on Tuesday June 07, 2011 @09:53AM (#36361840) Journal
    I suspect that the first question falls into the "Very interesting, pity we'll never find out..." category.

    As for the second, I suspect that it is largely a matter of manufacturing convenience and/or fob tamper resistance. With RSA doing the keyfill at point of manufacture, the customer just needs to load the seed file for the entire batch onto their authentication server and then hand out the tokens, which are glued shut with considerable enthusiasm, and have no externally accessible electrical connections of any sort. If the customer did the fill, that would be extra effort (and a step where grunt manual labor would meet very sensitive data, not a pleasant HR situation...) for them, and would mean that RSA would have to validate their design against attacks on the exposed connectors. Neither is impossible to overcome; but under the(now invalid) assumption that RSA wouldn't fuck it up, certainly easier to avoid than to deal with.
  • Re:two factor? (Score:2, Insightful)

    by Anonymous Coward on Tuesday June 07, 2011 @09:58AM (#36361882)

    They have got the key to generate the "random" token. So, yes, it's down to one factor.

    But I guess the password is the easy part.. Password reuse, keylogger, etc....

  • by Tim C ( 15259 ) on Tuesday June 07, 2011 @10:05AM (#36361940)

    I like how everything is now "under-secured" as if you have any first hand knowledge of the nature of the attack at RSA or the security measures they had in place.

    Someone got in. Seems to me that that is a very good, practical definition of "under-secured".

  • by asifyoucare ( 302582 ) on Tuesday June 07, 2011 @10:06AM (#36361958)

    Sitefinder. Unforgivable.

  • by TheRaven64 ( 641858 ) on Tuesday June 07, 2011 @10:14AM (#36362044) Journal
    Cold wars are better for business than fighting wars. In a cold war, you get lots of funding but don't actually have to deliver anything. Cyberwar is even better, because whatever you do deliver becomes obsolete about ten seconds after deployment (at the latest), so you can keep getting the funding. A cyberwar with China is perfect, because there's always the possibility that it will turn into a shooting war, so you need to keep spending money on jets, drones, aircraft carriers, and so on, but there's no real chance that it will, so you don't have to waste much money on things like soldiers (who inconveniently take money away from shareholders' pockets, where it belongs).

"Turn on, tune up, rock out." -- Billy Gibbons