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."
Is this an act of war? (Score:5, Interesting)
Re: (Score:2)
Why would it be? (Score:2)
No physical damage was done.
Re: (Score:2)
Re: (Score:2)
But surely now that Osama and Saddam are dead, they need some other people to add to the ol' war list in case they run out? Right now there's always camel-face and Kim Jong Il, but they must need a few more to keep the military cash flowing?
Re:Is this an act of war? (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
Cyber intrusions (Score:4, Insightful)
Re: (Score:3)
Ted Nelson was even complaining about its overuse [wiktionary.org] in the late 1960s. Seems not to have really stopped.
Re: (Score:2)
Re: (Score:2)
Cyber-group hug!
Re: (Score:2)
Re: (Score:2, Redundant)
OH MY GOD, DID YOU WARN THEM?!
(hello, lameness filter! how have you been?)
Re:Cyber intrusions (Score:5, Interesting)
...and 1947 turns the dial on its rotary phone to call both '92 and '84:
From here [theorem.net]:
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)
Re: (Score:2)
TerranFury has it right. Cyber=governer is the correct etemology. "Cyber" entered SciFi because it was thought that cybernetics (systems that govern themselves through feedback) would be the key to robotic prosthetics. Half-robot "cyborg" warriors were a fun addition to the genre. Of coruse, that later gave rise to "cyberpunk" novels, forever associating "cyber" with "internet" (even though Vernor Vinge predated all the cyberpunk guys with his ideas about an MMO-style internet in "True Names").
Dear Customers... (Score:5, Insightful)
Re: (Score:2)
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?
Re:Dear Customers... (Score:4, Insightful)
Re: (Score:3)
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?
Re: (Score:2)
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: (Score:2)
Never seen Mission Impossible eh.
Re:Dear Customers... (Score:4, Informative)
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...
Re:Dear Customers... (Score:4, Insightful)
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.
Re: (Score:2)
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]
Re: (Score:2)
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
Re: (Score:3)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Do you know how public key cryptography works?
Re: (Score:2)
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?
Re:Dear Customers... (Score:5, Insightful)
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: (Score:2)
Re: (Score:3)
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.
Re:Dear Customers... (Score:5, Insightful)
Re: (Score:3)
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)
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.
Re: (Score:3, Insightful)
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.
Re:Dear Customers... (Score:5, Insightful)
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.
Re: (Score:3)
Perhaps they kept them around for initializing more fobs if necessary without having to transfer the root key again. Granted, it would probably be better to use a new root key and have a system support multiple, but then you have a key distribution problem where you need to distribute another key as well. It might not have been the most secure choice, but it seems it could have a lot of benefits for the sake of convenience if they thought they had it protected enough. Everything in security is about trad
Re: (Score:3)
In simpler terms - convenience won out over security.
Re:Dear Customers... (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.
Re: (Score:2)
Wrong. The secret value in SecurID tokens is not some private key in a PKI. It's just a random number. There is no reason RSA couldn't just write these random numbers to write-only media and delete all other copies after sending them to the customer. There is no reason to keep them accessible on the network--let the support people sneaker-net the numbers if the customer loses theirs! That's the appropriate level of security for something as sensitive as this.
Of course, I'm sure they know this. The real reas
Re: (Score:2)
If the storage or machine containing the seed keys wasn't airgapped and in a safe, it was under-secured.
Because I know to do this and RSA doesn't, I 'd say I know how to properly secure a network better than RSA.
Re: (Score:2)
Re:Dear Customers... (Score:5, Insightful)
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".
Re: (Score:2)
Well, I bet the GP knows something about cryptography... And by knowing that, he probably knows that if RSA used some proper security, it would be impossible to retrieve the keys by attacking the server (as TFA says that happened). Thus, RSA didn't use propoer security.
Now, I have no idea why RSA didn't use propoer security, it may have even the client that demanded it.
Re: (Score:2)
'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."
We don't need the knowledge you tool. If a man can make it, then a man can break it, and a man can fix it, it's that simple.
Comment removed (Score:5, Insightful)
Re: (Score:2)
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.
Re: (Score:2)
but be scrambling.
*but *shouldn't* be scrambling
sorry edit ate text
Re: (Score:2)
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.
Re: (Score:3)
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:3)
Their public statement, and their NDA-protected message given directly to clients are two, very different things.
Comment removed (Score:4, Insightful)
Re: (Score:2)
And they worry about retailers and PCI (Score:2)
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
Re: (Score:3)
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
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yes. They should use a colocated server in a datacenter or a third-party payment processor if they're that small.
Re: (Score:2)
Re: (Score:2)
Anybody know? (Score:4, Interesting)
And the worst part.... (Score:2)
Re: (Score:2)
...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.
Re: (Score:2)
That's what knives, pennies/dimes, and nail files are for.
Re: (Score:2)
Re: (Score:3)
Which is great until you slip and stab yourself in the fucking hand.
So use use the hand not involved in carnal relations, duh.
RSA is Offering to Replace Tokens (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re:RSA is Offering to Replace Tokens (Score:5, Insightful)
We are committed to providing you with a customer experience commesurate with what we can get away with. XOXOXO,
RSA
Reparations (Score:5, Funny)
Nah, how about just offer them a "sorry" and a couple of old games and call it even?
Glad We switched to YubiKey long ago. (Score:5, Interesting)
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
If RSA has your keys... are they really secure?!?!!
Re: (Score:2)
"You got cheesy blasters!" and then meat cat flies away on his skateboard.
two factor? (Score:5, Insightful)
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)
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....
Re: (Score:2)
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....
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:3)
Re: (Score:2)
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?
Re: (Score:3)
Julie
Open Source Subnet [networkworld.com]
Who was watching RSA (Score:2)
After all, at a minimum they had the same access to these networks that the hackers do.
Seems like a low-tech approach might be best (Score:2)
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.
Re: (Score:2)
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.
House of cards... (Score:2)
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
Network Security (Score:2)
Re: (Score:2)
How else would it work? The things change every minute: that's 31.5 million different numbers across a year, and yours have to be different than anyone else's. You think they just fire up the old pseudorandom number generator and cat 30 million numbers into a file, then keep track of which set of 30 million numbers needs to go onto the fob for any given company that might order one? The numbers are calculated based on an algorithm, a seed (which is unique to every company) and the current time/date. Sin
Re: (Score:2)
Yep the RSA keyfob is basically doing something like an MD5-challenge (based on the time I'd assume) over SSL,* and this is like the private keys being stolen. It's not a one-time pad (which would actually be a pretty decent idea, but you'd need a new keyfob when the logins are depleted).
*Educated guess, I don't know exactly what it does
Re: (Score:2)
that wouldn't be at all practical. Why store millions of codes (one per minute for the lifetime of the devce) when very very few of them would be used. I use my RSA token maybe once a week on the days when I'm working from home.
2 minutes spent on wikipedia shows you g how 2 factor RSA authetication works.
Re: (Score:2)
As far as I can tell the only advantage of this RSA keyfob over SSH passphrased keyfiles on a flash drive is...
Well actually there isn't much of one. With the keyfiles on a flash drive, you have to physically steal the drive or get the data off the drive somehow, and then know the passphrase. If you physically steal this keyfob, you have the keys to the castle.
Re: (Score:2)
It's just a little compromised, it's still profitable, it's still profitable!
It's just a little copied, it's still profitable, it's still profitable!
Tech: [Crestfallen.] It's public.
Company: I know.
Re: (Score:2)
Young nerds go to public international crypto conferences, see the new big public math.
They run back to their employee and buy generation after generation of closed boxes promised to be based on the safe math they so enjoyed with their peers.