English   Deutsch   Русский   中文    

RSA SecurID breach: it had to happen...

Mar 21, 2011 by 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.


Author info

Sachar Paulus
Scientific Advisor
Profile | All posts
KuppingerCole Blog
KuppingerCole Select
Register now for KuppingerCole Select and get your free 30-day access to a great selection of KuppingerCole research materials and to live training sessions.
Register now
Cloud Risk & Security
Many organizations are concerned about the use of cloud services; the challenge is to securely enable the use of these services without negating and the benefits that they bring. To meet this challenge it is essential to move from IT Management to IT Governance.
KuppingerCole CLASS
Trusted Independent Advice in CLoud ASSurance including a detailed analysis of the Cloud Assurance management tasks in your company.
 KuppingerCole News

 KuppingerCole on Facebook

 KuppingerCole on Twitter

 KuppingerCole on Google+

 KuppingerCole on YouTube

 KuppingerCole at LinkedIn

 Our group at LinkedIn

 Our group at Xing
Imprint       General Terms and Conditions       Terms of Use       Privacy policy
© 2003-2015 KuppingerCole