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

RSA Admits SecurID Tokens Have Been Compromised 219

Posted by CmdrTaco
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."
This discussion has been archived. No new comments can be posted.

RSA Admits SecurID Tokens Have Been Compromised

Comments Filter:
  • by cultiv8 (1660093) on Tuesday June 07, 2011 @08:50AM (#36361234) Homepage
    Sit back peoples, get some popcorn, this should be interesting...
    • Expect a committee of jowled senators to make an official inquiry into how RSA's tubes were breached.
    • No physical damage was done.

    • by _Sprocket_ (42527)
      No more interesting than the old Cold War days. Espionage has always had the possibility of being called an act of war and "cyberwar" is no more than espionage in an environment with new tools and a low barrier to entry.
  • 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.
    • by Trepidity (597)

      Ted Nelson was even complaining about its overuse [wiktionary.org] in the late 1960s. Seems not to have really stopped.

    • Cyber hanky to you, for the trouble.
    • by timeOday (582209)
      Not gonna happen. The term "cyber security" is ubiquitous in defense and government circles. In fact "cyber" means "cyber security" now. If anything, I expect "cyber" will become more common among the broader field of computer security, the same way "hacker" won out over "cracker."
  • 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 amn108 (1231606)

      Do you know how their two-factor authentication works? How do you propose their system authenticates a client if it doesn't have a copy of the seed?

      • 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 c0lo (1497653)

          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?

          • And that copy should stay on an airgapped machine or storage device sitting in a safe, or at the very least, in a secure area on a separate network disconnected from the outside world.

          • Re:Dear Customers... (Score:4, Informative)

            by fuzzyfuzzyfungus (1223518) on Tuesday June 07, 2011 @09:48AM (#36361774) Journal
            If they need to check the list of seeds they've already used, their seed length is arguably way, way, way too short. With sufficient seed length, the risk isn't quite zero; but it is so vanishly close that it doesn't matter.

            Since the algorithm that the tokens use is public knowledge, anybody can, for a given seed, compute the token display value at time T. If the seed-space were so small that RSA needed to do duplicate checks, rather than just resting assured in the fact that they'd need to issue a fob to every proton in the universe before the risk of duplication rises above 1%, then there would be the theoretical danger that an attacker could just brute-force things by computing each seed chain, and then inferring the target fob's seed by sampling its output at one or more times and seeing which seed chain it matched...
          • 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.

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

              Stats 101: The odds of a collision between any two seeds is substantially higher than that: http://en.wikipedia.org/wiki/Birthday_paradox [wikipedia.org]

              • by 0123456 (636235)

                Stats 101: The odds of a collision between any two seeds is substantially higher than that: http://en.wikipedia.org/wiki/Birthday_paradox [wikipedia.org]

                But that's really irrelevant unless the company generating the seeds is inept and uses 8-bit seeds: if your seed contains as little as 128 bits and is truly random then you'd need to sell about 2^64 tokens before you'd expect a dupe.

                And why would it matter anyway? The odds of a cracker happening to buy a token which also matches the other token that they want to exploit would be minute... far less than the odds of said cracker managing to steal the seed from a stored copy on the manufacturer's server that's

      • by yodleboy (982200)
        i think his point was that they sell a "high security" product and then store the keys on an apparently "low security" network. probably a bad idea.
      • by hublan (197388)

        Perhaps by keeping the machine that hosts the seed secured? Like using a protocol between the publicly facing machine and the seed machine that doesn't allow for remote shell access? Really basic stuff, actually.

      • by thijsh (910751)
        Public/private key pairs... not rocket science, but I must admit close...
      • Do you know how public key cryptography works?

    • by wkk2 (808881)

      I have two questions: Did someone required them to keep the initial values and why wasn't the system designed so that the customer was required to initialize the tokens?

      • 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.
        • by wkk2 (808881)
          Yes, I'm sure we will never find out if the data was given to various agencies. After carefully opening one, I agree that they are tamper evident. It wouldn't be a big step to have two pins (I2C?) for programming from a simple workstation that also loaded the customer's server. A fuse link or finalize command could prevent future changes. I would hope the programming could be idiot proof but they keep making better idiots.
        • by makomk (752139)

          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.

          They don't do that though. As far as anyone outside RSA can tell, the keyfill port is a row of 7 PCB contacts hidden behind a little rectangular stick-on plastic cover on the back of the device. The cover doesn't even seem to be tamper-evident let alone tamper-resistant - you just press it back down again after you're done gawking and it sticks right back into place.

    • 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 swillden (191260)

        For master encryption keys anything other than offline physically secure storage is a risk that is too high

        I would agree with you if secure hardware security modules (HSMs) didn't exist. Buy a FIPS 140-2 Level 4 certified device, get people who know what they're doing to configure it for you (including ensuring that the device will never, under any circumstances, export the master keys) and it is acceptable to have the device networked. You still need to have strong physical security around it, though that's more to prevent the DOS attack that results from having the device stolen than due to concern about som

        • Re:Dear Customers... (Score:5, Informative)

          by PIBM (588930) <pbnadeau@g m a i l.com> on Tuesday June 07, 2011 @10:18AM (#36362078) Homepage

          I remembered reading about this, and the failure mode were quite important to me. Let me quote wikipedia on this:

          Section 4.1.1 of the specification describes additional attacks that may require mitigation, such as differential power analysis. If a product contains countermeasures against these attacks, they must be documented and tested, but protections are not required to achieve a given level. Thus, a criticism of FIPS 140-2 is that the standard gives a false sense of security at Levels 2 and above because the standard implies that modules will be tamper-evident and/or tamper-resistant, yet modules are permitted to have side channel vulnerabilities that allow simple extraction of keys.

  • 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 Amouth (879122)

      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.

      why would you need to scramble? shouldn't you be looking at this anyways? on a regular basis? sure this is a good reason to take a second look - but be scrambling.

      • by Amouth (879122)

        but be scrambling.

        *but *shouldn't* be scrambling

        sorry edit ate text

      • by vlm (69642)

        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.

        why would you need to scramble? shouldn't you be looking at this anyways? on a regular basis? sure this is a good reason to take a second look - but be scrambling.

        Having been there / done that, what he means is that today, over and above the normal procedure, some PHB around 5 to 10 levels higher in the org chart has mandated that he will call every person who logged in on the telephone and verify that at that time and date it was in fact that person who logged in and not someone else. Or similar level of foolishness.

      • A fair point, we should be looking anyway, but an increased threat means we should be looking even harder. If you believe that SecurId tokens are secure then you probably look for different things than you look for if you believe SecurId tokens are not secure.

        For example one of the things we're looking at closely is IP addresses authenticating more than one user. We've found a few and so far they're genuine, such as partner businesses' NAT addresses or a bunch of employees in the same hotel and same NAT.

        • by Amouth (879122)

          that is all fine and sounds good - but i don't consider that scrambling.. i guess to me its just a different meaning.. to me scrambling would be - having to figure out what needs to happen to be able to figure out where you are.

    • by erroneus (253617)

      They care more about their reputation than the service they provide. If someone else announces the problem, they are either "speculating" or they have dangerous inside knowledge which would be hard to prove without official acknowledgement from the company. But after so many others came out, it became increasingly difficult to "deny it without denying it" as their corporate lawyers and PR staff usually do. And at just about the same time that congress is beginning to wonder what's going on and call a hea

    • by AJH16 (940784)

      In fairness to RSA, they did release updated best practices to their clients right away and had reason to believe (accurately) that the attackers were interested in the defense industry specifically, so they focused on fixing that first. Really, as long as you lock your system down if someone starts using the wrong RSA token with the wrong username repeatedly, then the chances of an actual penetration are still pretty minimal, at least for any sizable key-space. It's not a situation that would occur in al

    • by Leebert (1694) *

      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.

      Have you read their statement [rsa.com]? They *still haven't* kept us informed. All they've said is that they'll replace the tokens, and that "the information taken from RSA in March has been used as an element of an attempted broader attack on Lockheed Martin".

      Nowhere have they said that the seeds are compromised, nowhere have they told us exactly what information was leaked, only that the leaked information played a role in the LM attack.

      The mind boggles.

      • by i_ate_god (899684)

        Their public statement, and their NDA-protected message given directly to clients are two, very different things.

  • RSA keys are compromised, Sony gets compromised, and meanwhile the bankcard industry continues to come down hard on independent retailers to force them to bring their internal systems into PCI compliance [pcisecuritystandards.org]. I know small retailers that have invested tens of thousands to secure their WiFi, update their firewall, upgrade their debit pads, all to protect cardholder data. Seriously, what criminal is going to target Joe's Hardware Store to snag a few hundred bankcards? These guys want the big targets. As Willie

    • by surgen (1145449)

      These guys want the big targets.

      What guys? Are you implying that every malicious actor is part of one large homogenous blob of shared targets and interests?

      Criminals are going to aim at the top of the food chain, not at the mom and pop store.

      Or they'll go for the low-hanging fruit, the payoff might be smaller, but they sure can hit a lot more targets.

      You're advocating "lets fly under they radar, we'll be fine", that's terrible security. Besides, if they really are that small, they don't really need the robust kind of credit card processing you're talking about. It'd be cheaper for them to get some self-contained units a

      • by John3 (85454)

        What I'm suggesting is that the bankcard industry is wetting their pants about retailer security and meanwhile the breaches are occurring at much more lucrative targets. I certainly think retailers need to secure their systems, but at what cost? For example, assume retailer has a secure WiFi network using WPA-2. That WiFi is on the same segment as their wired network. PCI standards require the business to segment the WiFi. That's obviously "best practice", but that means the business needs to invest in

        • Nah, they'll get an internet-connected PC and run your credit card through PayPal.
        • by smelch (1988698)
          Perhaps they are appearing in high profile targets because big corps are likely to notice they've been compromised, and its more newsworthy. When a plane goes down you hear about it, but more people than were on that plane died in auto accidents that day.
        • by jackbird (721605)

          PCI compliance requires servers be in a locked room. If the business is a three person operation and the server sits under the owners desk then is that really a big security risk, or should the owner of this small business build a secure server room?

          Yes. They should use a colocated server in a datacenter or a third-party payment processor if they're that small.

      • by Machtyn (759119)
        Having worked with small businesses in the past, I can guarantee they have to be just as vigilant at protecting customer data. It's not a happy day (for them) when they report they think they've been hacked and CC data has been stolen.
        • by Machtyn (759119)
          Oh, I should also mention, these small companies usually don't find out until one or more of their customer's cards have been compromised and the customer reports back to them. The lag time hurts.
  • Anybody know? (Score:4, Interesting)

    by fuzzyfuzzyfungus (1223518) on Tuesday June 07, 2011 @09:01AM (#36361322) Journal
    Are there any big, important checkbox-compliant certifications that RSA's customers might have been using the (Not Cheap) RSA tokens to obtain that, as a consequence of this sordid episode, might no longer be attainable with RSA gear? That seems like it would be a fitting punishment for RSA's questionable security practices and even more questionable disclosure practices; but I'm afraid that I haven't wrapped my head around the alphabet soup of compliance acronyms in different areas enough to know.
  • ...is that I'm going to have to fiddle around to get my RSA key fob off my keyring so I can put a new one on. Damn keyrings always end up hurting my nails.
    • by vlm (69642)

      ...is that I'm going to have to fiddle around to get my RSA key fob off my keyring so I can put a new one on. Damn keyrings always end up hurting my nails.

      A really cool hack would be replicating the operation of a keyfob using the very stereotypical ardweeno board or any other microcontroller. Or even a small perl script.

      By replication, I don't mean a small box that outputs a periodically changing random number on a LCD like a movie prop, but I mean a replication of my actual fob, that when used, successfully lets me log into a VPN. Now that would be cool. I haven't seen one yet.

    • by Mashiki (184564)

      That's what knives, pennies/dimes, and nail files are for.

      • by wjousts (1529427)
        Which is great until you slip and stab yourself in the fucking hand.
        • by Anomalyst (742352)

          Which is great until you slip and stab yourself in the fucking hand.

          So use use the hand not involved in carnal relations, duh.

  • by chill (34294) on Tuesday June 07, 2011 @09:06AM (#36361360) Journal

    Here is a link to RSA's official statement [rsa.com] made yesterday. They are offering to replace tokens for "customers with concentrated user bases typically focused on protecting intellectual property and corporate networks".

    That is corporate VPN, not the people who use tokens issued to get to websites, such as banking info.

    • by AJH16 (940784)

      They are offering transaction monitoring to financial providers. The difference is distribution of the tokens. The tokens themselves are probably pretty cheap, but securely distributing millions of tokens to remotely located users is a non-trivial task with a lot of additional cost. Also, distributing new tokens doesn't gain a lot over monitoring in that case. Unless you know the particular id of the token in use by a given user, you would have to guess from the pool of tokens used by that organization.

    • by garyok (218493)

      In the case of banking info, I'd assume it was the bank that issued the SecurID token to be RSA's customer. So all those tokens will be getting replaced. At least that's how it works in the UK. If a bank told me to I had to pay for their mandated authentication hardware, I'd tell them to get stuffed.

      Looks like that move to HSBC is off for the moment. Their internet banking was crappy anyway.

  • Reparations (Score:5, Funny)

    by TardisX (15222) on Tuesday June 07, 2011 @09:18AM (#36361454)

    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?

  • Our secure tokens are Yubikeys [yubico.com]. We use RFID for physical access and the challenge response protocol for authentication.

    We didn't like the thought of having to trust a 3rd party with our keys, so we run our own authentication services and use our own "seeds". This way we have one less attack/exploit surface (the MFG) to worry about -- Looks like it paid off for us this time!

    Key Lifecycle Management

    Re-configuration of YubiKeys by customers

    For high security environments, customers may select not to share the
    AES key information for their YubiKeys outside of their organization.
    Customers may also for other reasons want to be in control of all AES
    keys programmed into the Yubikey devices. Yubico therefore supports the
    use of a personalization tool to reconfigure the YubiKeys with new AES
    keys and meta data.

    If RSA has your keys... are they really secure?!?!!

  • 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?

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      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 vlm (69642)

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

        OK that's exactly what I'm looking for. So its no worse than dropping back to "one factor". The two apps/systems/companies I have personal experience with that use securid use two factor only as security theater, not a realistic threat model, not for legal compliance, etc, so they're safe.

        I was worried for a minute someone found a back door, like you can bypass any securid "protected" login using all nines as a password, you know, something like Sony would use....

        • by guruevi (827432)

          The problem IS those companies that only use it for security theater. I can tell you, many companies I've seen allow the RSA key to be used as a password by itself practically making it a single factor authentication model or once they have the RSA keys, downplay the need for strong passwords. A lot of outside contractors get a single character password or a simple or repeated password and then use the token as the rest of the password.

        • by makomk (752139)

          OK that's exactly what I'm looking for. So its no worse than dropping back to "one factor".

          Unfortunately, RSA have tended to encourage customers to use a 4 digit numeric password with SecurID in the past because the security of the dongle supposedly made this safe, and this is the single factor that their level of security has now been reduced too. Hence why they were so keen to encourage the use of strong passwords by their customers when they first discovered they'd been hacked.

      • by vlm (69642)

        is determined by a secret RSA-developed algorthm

        The algorithm is already public knowledge.

        Article is better written than most, or at least better cut and pasted, but needs editing. Which is it? Secret or public?

    • by Julie188 (991243)
      It says that RSA isn't really coming clean with the details. Story says, "Coviello defended the company's decision by saying that they didn't want to reveal to the hackers how to mount further attacks." Of course, blackhats already know how to mount the attack ... by not coming clean with the details the ones that don't know how this happened and what they could be doing to protect themselves are the users.

      Julie
      Open Source Subnet [networkworld.com]
  • After all, at a minimum they had the same access to these networks that the hackers do.

  • If you need to keep this machine super-secure and only serving a specific kind of data.....then talk to it via a serial port. No network stacks, no "oh that machine was under-utilized, so we added this function", no nuthin. I hated serial back in the day, but if this shit is going to keep happening, then kill it with fire.

    • You simply don't want to have such a machine. You either use a hardware based true random number generator for seeding your random number generator, or you trust the number generation to your client. Also, you don't get to keep history of the seeds, or the private keys.

  • Serves them (rsa's customers) right for not understanding what it is they were buying into...

    A system where someone else generates and retains a copy of all the keys, requiring you to have blind faith in that party to keep them secure... Did noone else see the serious flaws in such a system?

    In order to build a secure system, look at encryption...
    How encryption works is well known, the major algorithms are public knowledge, and are tried and tested. And yet the keys, when used properly are known only to the

  • If I were in business doing high security work, I would design a secure network that is physically separate from the corporate one and have all jacks on the secure network colored in red with red cables. No software development related to high security work or high security information would be allowed on the corporate network. There would be no permanent connection to the outside world from the secure network. In the event that data does need to be transmitted, I would use a dial-on-demand style connect

All programmers are playwrights and all computers are lousy actors.

Working...