Blog
I like this
I don't like this

RSA SecurID breach: it had to happen...

Mar 21, 2011
Sachar Paulus

As you, dear reader, can imagine, the information about the SecurID breach was really shaking the minds of us analysts here - for a long time, we were telling the story that SecurID was the right compromise between security, convenience and manageability - until SMS became so cheap, that they made the first place for cheap, manageable and strong authentication.

There has been said much about the management aspects, whether it will shake the industry (I personally believe, yes, but much slower than some people argue) or what this means for the reputation of the world's largest strong authentication player. I want to add my few cents on the concept itself.

To do that, I need to go back in time when I was a postdoc, some (ugh, more than 15) years ago. We were working on analyzing the strong authentication landscape, and of course SecurID was already there, with a remarkable footprint in the market. We analyzed a number of technologies, including PKI with different crypto systems, one-way functions for authentication purposes, HMACs and so on, among others, of course, the market leader, SecurID.  But what really made us worry - and remember, it was the time where Europe feared that the U.S. can hear and do everything in our IT-systems - were two observations:

  1. The algorithm of SecurID was kept secret, and there was no way for us post doc researchers to get our hands on the code or even an algorithm and
  2. The fact that there were a number of open, secure and understood algorithms doing basically the same thing.
In fact, soon after our team developed an HMAC based authentication algorithm with Smart Cards and mobile readers that was adopted by a number of German players - which, of course from todays perspective, did not succeed. But back to SecurID - so we wondered why such an important player could sell - technology-wise, and in the eyes of a security designer - such a crap thing so well...

We went on, analyzing it without having our hands on the code, and found in our eyes a serious weakness, that was to our understanding by no means due for keeping the security tight: some information pieces about EVERY user (in fact, about every token) was kept at the site of the customer. And the reason was not user experience, either: because if you loose your token, then you need to go through a re-personalization process, so it was not for that purpose... So why was this necessary? Of course - remember the times - we were imaging a number of more political than technical reasons...

Anyway - it was, and it is, an important weakness of the protocol, since it offers an unnecessary attack vector. Any other clever hacker could have come to that same conclusion. Now with the right motivation, the right customers - there you go!

It simply had to happen one day.