12 ms·
RSA finally comes clean: SecurID is compromised
- AndyNemmity 15y agoOur securid's from RSA were replaced weeks ago in mass. I work for a well known large company, is it just the news is late?
- Devilboy 15y agoYes the Lockheed Martin thing happened last month, it's just taken this long for RSA to publicly admit that it has a serious problem.
- dekz 15y ago> It's taken this long for the RSA Lawyers to allow a public statement Fixed that for you. Customers were notified and I believe many a secureid token was replaced, at least for all mission critical businesses. That letter to the public would have been second to the priority of customer notifications, even sony was late in their press release -- carefully wording their response to forgo accepting blame. Since the attack was "thwarted" we can assume that RSA did in fact communicate with these businesses and shared the knowledge of the potential attack. It's not a "serious problem" like if the fundamental cryptology is flawed or implemented with a level of security through obscurity. The only "serious problem" was storing seeds for some unknown reason. If your seed wasn't stored then you have nothing to worry about, and I can only assume if you were contacted by someone from RSA(personally) than you should probably assume your seed was stored. One would hope that a business like Lockheed Martin then setup a honey pot to try and gather information on the attackers logging in with these compromised SecureIDs.
- timson 15y ago> The only "serious problem" was storing seeds for some unknown reason. I read somewhere else that the seeds are stored by RSA as an additional backup for the customers. In the event that the customer accidentally loses their seed database, it would be a very costly operation to replace all the SecurID hardware tokens. But... well... they are forced to replace all the SecurID hardware tokens anyway.
- deleted 15y ago[deleted]
- ceejayoz 15y ago> In the event that the customer accidentally loses their seed database, it would be a very costly operation to replace all the SecurID hardware tokens. It'd be a very profitable operation for RSA, so I doubt this explanation.
- dekz 15y agoI read similar, but there is no excuse for that machine to be connected to the internet.
- deleted 15y ago[deleted]
- FeministHacker 15y agoI can also confirm that a lot of interesting things did go on weeks or months ago for some people. More than that I can't say.
- drivebyacct2 15y agoDidn't we know this when the breach originally occured? Or after there was a major break in? Oh, it's "official" now. Good thing they were responsible about it.
- zitterbewegung 15y agoHappened last month. http://www.engadget.com/2011/03/18/rsa-hacked-data-exposed-that-could-reduce-the-effectiveness-o/ http://www.engadget.com/2011/03/18/rsa-hacked-data-exposed-t... Lockheed Martin Breach http://www.infoworld.com/t/hacking/lockheed-hack-should-put-the-us-high-alert-329 http://www.infoworld.com/t/hacking/lockheed-hack-should-put-... (This happened a few weeks ago) I remember hearing it earlier.
- drivebyacct2 15y agoYeah, that was my point.
- kprobst 15y agoFunny thing that, I'm holding a SecureID token in my hand right now, having just remoted into the corp network via VPN. Thanks RSA.
- deleted 15y ago[deleted]
- deleted 15y ago[deleted]
- skimbrel 15y agoThis is nitpicky, but shouldn't the title (on Ars I guess, since it was used verbatim) be "was compromised" since this was a one-time data theft that rendered all currently-live SecurID tokens useless?
- jvdh 15y agoTrue, on the other hand there are still 40 million of those tokens out there, which are all compromised and have to be replaced. So that is still very much present tense.
- tedjdziuba 15y agoHm, defense contractors were attacked, and it's taken so long for RSA to acknowledge the compromise to the rest of the world? It's was most definitely perpetrated by a government, and it's taken so long for them to respond because our government has been assessing the damage.
- rdl 15y agoThis is one of those cases where I really hate NDAs.
- adulau 15y agoThere is fundamental issue about those kind of tokens. The customer is not able to renew or set the private key (seed in RSA terms) of their tokens. It's a kind of insecure business model where the customer has no control over the tokens and is bound to the security of the supplier (if the supplier is compromised...). There are solutions like Yubikey or other compliant HOTP/TOTP tokens where the customer has the control of the private keys inside the token.
- InclinedPlane 15y agoIndeed. It's rather shoddy engineering if you ask me. Consider that, for example, SSL certs are generated and the private key is never disclosed to the cert authority when purchasing a key. That way only the owner of the SSL cert can actually use it.
- bigiain 15y ago"That way only the owner of the SSL cert can actually use it." Errrmmm, I'm not entirely sure that's correct - I wonder how many of Sony's private keys are in scriptkiddies hands right now? The webserver needs access to the private key. Anyone who gets root on the webserver can read the private key.
- joch 15y agoNot entirely sure that's correct either. One could use a Hardware Security Module, such as the Thales nShield Connect[1], which will keep the private keys secure (at least in theory). [1] http://www.thales-esecurity.com/Products/Hardware%20Security%20Modules/nShield%20Connect.aspx http://www.thales-esecurity.com/Products/Hardware%20Security...
- arethuza 15y agoInteresting, I've used personal and server based HSMs for XML and PDF document signing applications, I didn't know you got them for SSL as well.
- eik3_de 15y agoCan anyone compare this to Google's two-factor authentication using the Authenticator App? The app is open source (http://code.google.com/p/google-authenticator/ http://code.google.com/p/google-authenticator/) and the private key(correct?) is provided via a QR scan.
- eli 15y agoIt's the same concept, yes. And if the servers running the Authenticator at Google were hacked this system would likely be broken (but you'd also have much bigger problems)
- blibble 15y agothere's no online component... your phone takes the current time (divided by some value), the secret key, and performs a cryptographic function on it, then the system you're logging into does the same thing and compares the results. with secureid the secret key is fixed in the hardware (and RSA keep a copy of the key), whereas with Google authenticator you can generate and input the key yourself, so that Google never sees it.
- eli 15y agoI think one of us is confused. RSA's seed is the same as Authenticator's secret key, no? There's no online component in the RSA system either.
- eik3_de 15y ago> there's no online component I can confirm that. The app doesn't require any permissions. I rebooted my phone while in flight mode and the Google login via Authenticator code works as expected.
- dsl 15y ago> you can generate and input the key yourself, so that Google never sees it. Google still needs to know the secret. All authenticators are based on a shared secret model, so the same possible attack vector that bit RSA.
- KiwiNige 15y agoIf I'm understanding this correctly, then an attacker still has to know which seed is linked to my token in order to use it? Or can they reverse engineer that if they catch sight of one number? Edit: Spelling
- jvdh 15y agoQuote from the article: Sources close to RSA tell Ars that the March breach did indeed result in seeds being compromised. The algorithm is already public knowledge. As a result, SecurID offered no defense against the hackers that broke into RSA in March. For those hackers, SecurID was rendered equivalent to basic password authentication, with all the vulnerability to keyloggers and password reuse that entails. So they got a lot of the seeds and then were basically down to trial and error, similar to know passwords.
- chmike 15y agoSo the seeds are in fact equivalent to a signature made with symmetric keys... If the SecureID card used asymmetric keys with a truly private key, such incident could not have happened. Using private keys stored in a hardware carried with the owner with a challenge Q&A seems more secure.
- jongraehl 15y agoThe SecureID device S computes S(s,t) without any input from the server the user is authenticating to. t is synchronized time and available to everyone. s is a secret specific to that device. I don't know if it's a shared secret, but the compromise suggests that either it is, or RSA kept the 'private key' part on their servers for convenience. You're right that a different device S' that received a challenge c from the server and computed S'(c,s,t) could offer more security via public key crypto. But it would take more power (if communicating to the client machine to avoid user transcription of the challenge) or have a more cumbersome UI. I'll bet such devices are already sold.
- cnkeller 15y agoIt seems that they were reduced to guessing the PIN's and/or brute forcing them, hence the initial comment from RSA about increasing PIN length. One would have hoped that the LMC admins would have detected a brute force attack against their RSA servers, I guess they were already infested with keyloggers?
- mixmastamyk 15y agoSteve Gibson and Leo have been talking about this for weeks on the Security Now podcast. Interesting story if you'd like to listen. Amazing how a well known security company kept its crown jewels within reach general employees with Windows boxes. When are they gonna learn?
- iwwr 15y agoNot only that, they have employed a security-by-obscurity strategy: RSA Security Chairman Art Coviello said that the reason RSA had not disclosed the full extent of the vulnerability because doing so would have revealed to the hackers how to perform further attacks.
- edanm 15y agoIn their "defense", keeping it secret might have had more to do with saving their public image than with any belief that it was actually better security.
- dekz 15y agoI don't think so. More a long the lines of not disclosing all the companies who may have had their seed stored as it would provide these intruders with a list of targets to attempt to phish their pins.
- 7952 15y agoAlthough RSA were absolutely at fault it seems like a design failure that the seeds cannot be revoked. Give the keys 4 possible seeds and put 3 of them in a safe. Security is about having defence in depth.
- sliverstorm 15y agoHow do you update the tokens though? They need to be simple, no hooking into the internet.
- guan 15y agoThey could maybe have a single button that allows you to switch to a backup seed with some elaborate sequence of presses.
- 16s 15y agoI've programmed some for OTP devices. Vasco primarily, but some RSA too. Normally, the OTP algorithm takes two args... a "shared secret" (each customer has a different secret) and the exact date/time. All the fobs and the back-end server know/share the secret. On the fob thingy, one calculation occurs. The fob can be physical or virtual. So you may have a physical key fob or a virtual software fob for your blackberry, iPhone, Droid, etc. They even work with dumb phones over SMS. Either way, the same calculation occurs. Again, it looks something like this: const unsigned int OTP ( const string& shared_secret, const time& time_of_day ) { return OTP; } So when you push the button on the fob (or just look at it if it's the always on type), it returns an OTP. On the server, the exact same calculation occurs except that it calculates a range of OTPs (in case the time on the fob has drifted... and this does indeed occur). A minute or so worth of calculations. The fob's OTP must fall into the server's calculated range, if not, the OTP will fail and the fob will need to be recalibrated (resync its clock). So, if this story is true, then the list of customer shared secrets was stolen and whoever has them now knows that company X uses secret Y on their fobs. It's hard to believe that RSA actually had a list matching company names to shared secrets unencrypted. I'm not sure I believe that.
- jeffreyg 15y ago> It's hard to believe that RSA actually had a list matching company names to shared secrets unencrypted. I'm not sure I believe that. If you don't believe it, what other attack/compromise do you suppose took place?
- mentat 15y agoIt doesn't matter if it was store unencrypted if they could capture the credentials used to decrypt it. It was previously disclosed that they managed to get credentials and administrator / root level access through large parts of RSA. Do you think that this level of acces would still be unable to access the database?
- johno215 15y agoIt is sad how the comments here are much better than at Ars. [I wish Ars would implement threading and a silent karma system]