Slashdot Mirror

← Back to Stories (view on slashdot.org)

RSA Admits SecurID Tokens Have Been Compromised

Posted by CmdrTaco on from the hey-i-have-one-of-those dept.

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."

7 of 219 comments (clear)

  1. Dear Customers... by fuzzyfuzzyfungus · · Score: 5, Insightful

    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?

    1. Re:Dear Customers... by fuzzyfuzzyfungus · · Score: 5, Insightful

      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.

    2. Re:Dear Customers... by thijsh · · Score: 5, Insightful

      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.

    3. Re:Dear Customers... by fuzzyfuzzyfungus · · Score: 5, Insightful

      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.

    4. Re:Dear Customers... by clodney · · Score: 5, Interesting

      Admittedly for a company in the security business they get a big fail on this one.

      But I suspect that properly securing them is more difficult than it would appear to the outside observer. At one job I had, we had a signing key of some sort, which was on a USB key in a sealed envelope in a safe. We only took that key out when it needed to be used, which was maybe once a year. Easy enough to observe all the necessary precautions, even if it felt like overkill.

      But remember that RSA presumably manufactures these tokens every single day. So the seed values have to be handled correctly all the time, and that makes the air gap restrictions tremendously onerous to comply with. The seed values need to be known to the authentication servers, and customers will likely demand that RSA could provide them the necessary data to reload authentication servers in the event of a major crash (yes, I know, backups, etc. - but the real world is not always like that).

      So I suspect that RSA themselves was hurt by the classic security vs usability tradeoff. They need ongoing access to the data that they need to keep secure, and the security restrictions impacted usability, to the point where the policies were weakened, either officially or just by being sloppy.

      Defenders have to be good all the time. Attackers only have to succeed once.

  2. Re:Cyber intrusions by TerranFury · · Score: 5, Interesting

    ...and 1947 turns the dial on its rotary phone to call both '92 and '84:

    From here:

    It is worth noting that the Greek word for governor is k u ße r n a n . In 1947, Norbert Wiener at MIT was searching for a name for his new discipline of automata theory- control and communication in man and machine. In investigating the flyball governor of Watt, he investigated also the etymology of the word k u ße r n a n and came across the Greek word for steersman, k u ße r n t V . Thus, he selected the name cybernetics for his fledgling field.

    In other words...

    (Cyber = steering/adjustment/feedback) + (net = networks/interconnection) + (ics = study of)

  3. Reparations by TardisX · · Score: 5, Funny

    RSA is expected to replace practically every one of the 40 million SecurID tokens currently used.

    Nah, how about just offer them a "sorry" and a couple of old games and call it even?

    --

    Command attempted to use minibuffer while in minibuffer