Not so fast about SecurID

There wasn't really a point to comment on the RSA incident, as a lot of good people already said. There's not enough information to talk about and a lot of the news circulating around are just noise or bad opportunistic marketing. However, I noticed a lot of "assume SecurID is broken" advice in the last two days, and I thought I should say why I don't necessarily agree with that.

First, there's not much to "break" in SecurID. The algorithm had been reverse engineered a long time ago, so I don't have reasons to believe the leaked information is related to the algorithm itself. Only an issue with the algorithm would make the whole solution permanently useless, and I think it would have been found by now, no matter if a breach in RSA occurred or not.

Without an algorithm weakness, two main possibilities  remain. A very unlikely one (although there are some rumours about it) is the existence of a backdoor in the product. If that's the case it would only require a patch to ACE Server to fix it. It would certainly produce a huge damage to RSA reputation, but it's not something that would be very hard to fix. If that was the case they would have provided the fix together with the initial breach announcement, as the compensating controls they suggested to clients wouldn't make any sense if a backdoor was involved.

The last possibility is related to seed information. The seeds are the biggest secret of the SecurID solution, shared between the ACE Server and the user's token. They could have been compromised in the format of a database containing seed/serial number pairs or an eventual secret algorithm to generate seeds based on serial numbers. This last option would be pretty bad, as it would require the replacement of all tokens out there.

Anyway, if the issue is related to the seeds, the suggestions RSA made to its clients make sense, they are trying to increase the resistance of the remaining controls in a SecurID implementation. Also, if the seeds are compromised, an attacker, in order to successfully authenticate as a SecurID user, would have to:

1. Know the correct user identification

2. Know the user SecurID PIN

3. In most cases, to know the user password (SecurID is usually implemented in addition to an existent password authentication)

4. Know the user's token serial number

I never lease my token where it could be managed by anyone, so I'm sure that its serial number is reasonably protected. And I haven't even considered the PIN yet, that would require a keylogger or something similar to be obtained. Add to it active monitoring of RSA authentication logs and you still have some considerable resistance to authentication attacks.

As we can see, it's still not easy. In my opinion, it's quite different from "assume it's broken". It is less effective for sure, but it doesn't mean you should assume it's just not there. Probably something will have to be done to bring the security level back to where it was before, but your risk assessment will probably indicate you can wait until more information is provided by RSA.

By the way, I'm also not the only one saying that. This post from SANS ISC is saying exactly the same thing.