RSA SecurID news

[stine_]

Does anyone have any recommendation for login security since the report on the latest news about the RSA website?

re: `http://threatpost.com/en_us/blogs/rsa-warns-customers-targeted-attacks-wake-hack-031811

Login/Password + RSA/passphrase + Personal certificates?

Other tokens (WiKID or other)?

Or is it possible that the fallout from this won't be as bad as it could be?

[Ray_]

If you have lockouts enabled, consider lengthening them. I don't see that the ability to reproduce a token itself is important even if they know which company it belongs to. It would be like finding a piece of paper on company letterhead labeled "Passwords - Confidential".

You don't have a user name to go with the token and you don't even know where it's used.

The scariest speculation I read is this: "What if they got the source code and found a backdoor that RSA installed for use by the federal government so RSA could export SecurID?"

That would be a game changer.

Ray

[stine_]

That depends on the size of the company, and whether username+token/passphrase is the only security.

This also points to the flaw of using FirstInitalLastname (jdoe) as login name. (I've considered changing my name to R Oot several times over the last 20 years...of course, A D'min would be another good one)

If there are only a dozen employees, it would take about 1 minute to try all of them.   Of course, with the use of a bot network, you could do the same thing with 10k accounts....of course, you'd out the botnet (or tor exit nodes) doing it.

As for the back door. that's an interesting one.  Do you think they'd blackmail RSA, out the feds, or publish it to wikileaks? or do all three in that order?

On another note, has anyone seen clandestine job offers being made to these anonymous individuals?

[untruenorth_]

My thoughts - no claim to be correct about this.

The algorithm that the SecurID token implements is thought to be public, and if you google it, you can find code that claims to implement it in software. This isn't news. Since any crypto or auth system should not rely on the secrecy of the algorithm for its security, this shouldn't worry anyone unduly. 

We could speculate that the worst case is therefore that the seed record/token serial and customer records have been stolen. i.e. an attacker knows the range of token serials allocated to a company, and their associated seed records.

In that scenario, a successful attack would comprise:-

 - finding an RSA-authenticated entry point for that customer (i.e. their SSL VPN, mostly trivial to do)

 - determining a valid username and working out the token serial/seed record that is associated with that user (probably through social engineering)

 - sniffing, brute-forcing or socially engineering the PIN

Some or all of lockout policies, PIN complexity, suspicious activity monitoring, secondary authentication and robust user education should make this highly unlikely. 

At least - that's where my thoughts are right now.

What other scenarios have you all been thinking about?

[fuman_]

For me, all i got out of that nebulous Statement from this vendor was NOT TO OTP-only...

But who will do this ever in any case ??

So at the moment best will be Username + highly secure Password (complexity) in Combination with

At least secure PIN (as long as possible) and the Tokencode. Some Users won't like it.....

In the worst scenario security will rely more on the complexity of passwort and Pin than on the tokencode, but i think they won't tell us what really was extracted.

Sure, Client certificates will help to mitigate the risk, but this will produce more organizational overhead to maintain (for endusers and Admins)

I hope they did not loose serials and seeds of distributed tokens........ i could imagine something like this....but this is just a thought.

Sincerely

A RSA User (sitting in front of its RSA Monitor and waiting for unusual login attemps all night long :-)...)