Linked by anonymous on Tue 7th Jun 2011 15:34 UTC
Privacy, Security, Encryption 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.
Order by: Score:
let's hope we can get rid of those keys
by stofke on Tue 7th Jun 2011 17:29 UTC
stofke
Member since:
2011-02-27

I really hate those keys. All banks use a similar system linked to your bankcard to login but KeyTrade has these RSA keys.

So you need to enter like dozens of keys and codes just to login. In the end you just write it down on a piece of paper next to the PC just to remember the stuff. Bye security!

I always forget how to use these, such a PITA, I do hope this is the end of these keys.

Edited 2011-06-07 17:29 UTC

Reply Score: 1

umccullough Member since:
2006-01-26

In the end you just write it down on a piece of paper next to the PC just to remember the stuff. Bye security!


Obviously, you're referring to something different - that is not how RSA's SecurID works. There's nothing you can write down, the key value shown on the display changes 30 seconds or so, and this is synchronized with a server-side key value that also changes at the same time.

That is PRECISELY why these keys exist, so that users must have them in their possession to be authenticated. That's the generally-accepted definition of two-factor: authentication by something you know + something you have.

Edit: Re-reading your post, I think I understand why you don't get it... you keep trying to write down the key and re-use it again? um... no.

Edited 2011-06-07 21:01 UTC

Reply Score: 3

Delgarde Member since:
2008-08-19

That is PRECISELY why these keys exist, so that users must have them in their possession to be authenticated.


Well, that's the theory, at least. But it somewhat falls down if someone manages to get hold of the random seeds that the hardware keys work off, as the article suggests has happened...

Reply Score: 2

umccullough Member since:
2006-01-26

"That is PRECISELY why these keys exist, so that users must have them in their possession to be authenticated.


Well, that's the theory, at least. But it somewhat falls down if someone manages to get hold of the random seeds that the hardware keys work off, as the article suggests has happened...
"

Yup, good thing those people should *also* have a strong password that must be brute-forced -- and if they used public/private key challenge/response in combination with the securid tokens, that could be a pretty big hurdle to overcome for someone who was only able to compromise one of the two methods.

In theory, with two-factor authentication, you can more easily identify when one of the two mechanisms has been compromised before the other one can be brute-forced.

Anyhow, I don't care all that much - RSA isn't one of my favorite "security" companies.

Reply Score: 2

keys + third parties
by Alfman on Wed 8th Jun 2011 01:33 UTC
Alfman
Member since:
2011-01-28

The lesson to be learned here is that it is unwise to rely on a third party (RSA) to manage the security of inhouse systems.

In general I actually think one time key generators such as RSA's are a good idea. But not if a third party keeps a copy of the keys.

This may sound obvious, but people don't always realize the number of entities who have keys into their system.

In theory, since oracle has control of java updates, they could install backdoors to perform corporate espionage. This may be far fetched, but it is not implausible.

The firefox guys could use FF update to plant bugs, so could chrome. (Hmm, google has a known history of doing this anyways, so it's less of a conspiracy with them.)

MS could do the same thing.

Reply Score: 2

RE: keys + third parties
by AndrewZ on Wed 8th Jun 2011 19:19 UTC in reply to "keys + third parties"
AndrewZ Member since:
2005-11-15

The lesson to be learned here is that it is unwise to rely on a third party (RSA) to manage the security of inhouse systems.

The only thing worse is doing it in house :-)

Reply Score: 2

RE[2]: keys + third parties
by Alfman on Thu 9th Jun 2011 01:36 UTC in reply to "RE: keys + third parties"
Alfman Member since:
2011-01-28

AndrewZ,

"The only thing worse is doing it in house :-)"

Haha, well maybe.

But it is extremely troubling that RSA kept the keys (or pseudo random key generator) in the first place.

What legitimate purpose does RSA have to know the keys on their customer's systems (whether they're a trusted party or not)?

If I understand the incident correctly, this leak would not have been possible if RSA had disposed of it's keys after sending them to the customer. This sounds like gross negligence.

Reply Score: 2

RE: keys + third parties
by Soulbender on Thu 9th Jun 2011 16:34 UTC in reply to "keys + third parties"
Soulbender Member since:
2005-08-18

I guess another thing to take away is not to use secret sauce security, especially the kind that relies on some single, centrally managed secret.

Reply Score: 2

RE[2]: keys + third parties
by Alfman on Fri 10th Jun 2011 01:43 UTC in reply to "RE: keys + third parties"
Alfman Member since:
2011-01-28

Soulbender,

"I guess another thing to take away is not to use secret sauce security, especially the kind that relies on some single, centrally managed secret."


You are right, but good cryptography doesn't rely on secret sauce, only secret end user toppings (gosh, I'm not feeling the analogy).

The attacks were certainly newsworthy, but I hope that RSA does more than just fix the leak. I hope they scrub the customer keys from their systems.

Reply Score: 2