Is Token Based 2-Factor Authentication Really That Secure?

15 09 2011

When I told my bank that I wanted to use internet banking, they gave me along with my welcome package, a pocket-sized hardware device consisting of a small display and button. Each time I pressed the button, numbers would come up on the display. Every few seconds, a new number came up. To log on to the internet banking website, I had to key in my userid, password and the number displayed on the hardware device.

This was one of the most popular ways for 2-factor authentication (2FA). The hardware device, which was called a token would continuously generate new numbers. As such, even if a hacker were to get hold of my userid and password, he/she would not be able to access my account without access to my hardware device; the numbers changed so frequently that it was impossible for a hacker to guess those numbers. I was told that this was the ultimate protection against any security threats.

If only it was so simple. On March 17, 2011, RSA announced that there was a successful attack on its systems which caused the compromise of its RSA SecurID 2FA products [1]. RSA downplayed the significance of that attack, and wrote that the incident “does not enable a successful direct attack on any of our RSA SecurID customers” [1].

Unfortunately, that was not the case. On June 2, 2011, RSA confirmed that the information taken from the attack in March had been used for an attempted attack on Lockheed Martin [2]. In fact, it was confirmed that the attackers duplicated Lockheed’s SecurID tokens using the data stolen from RSA [3]. The actual details of what happened and how the compromise occurred was not released, and may well never be known. After the attack, RSA offered to replace SecurID tokens “for customers with concentrated user bases” [2]. For other companies who do not meet these criteria, the SecurID tokens which they continue to use with its compromised security might again be exploited by an attacker in the future.

The problem lies not so much with the attack on RSA as it is with the vulnerability of the token-based system. Each token comes with an embedded seed which is linked to a unique serial number. The seed is then combined with the current time through the use of an algorithm to produce a rotating code [4]. This method is used by almost all tokens today. At the back-end server, the serial number of all the tokens issued is stored, along with the seed pairs. The same algorithm on the back-end server is applied to get the same rotating code. So each time the user logs onto the system, the rotating code generated by the token is matched with the rotating code generated by the back-end server.

The main security threat is for an attacker to get the serial number and seed pairs of the issued tokens, which was likely what happened in RSA’s case. The algorithm to generate the code from the seed would likely be easily available, based on Kerckhoffs’ principle of making the algorithm public. As such, an attacker could just generate the rotating code without needing access to the token. There is a single point of failure; the attacker which can hack the back-end server would have access to all the seed pairs, compromising the security of the millions of tokens that were issued.

In conclusion, I have no doubt that adding a token-based authentication mechanism to implement 2FA adds to the standard level of userid and password kind of security. What I am saying is that it may not be the ultimate form of security after all and should still be implemented with other security measures – like the need for strong passwords, proper auditing and controls. This is especially so when such token based 2FA systems are used in highly sensitive situations such as internet banking, access to corporate VPNs and confidential systems.

[1] Coviello, A. W. (2011). Open letter to RSA Customers. Retrieved from http://www.rsa.com/node.aspx?id=3872

[2] Coviello, A. W. (2011). Open letter to RSA SecurID Customers. Retrieved from http://www.rsa.com/node.aspx?id=3891

[3] Hall, J. (2011). The RSA SecurD Compromise: Analysis & Response. Retrieved from http://www.cbts.cinbell.com/whitepapers/rsasecuridattack

[4] Jarmoc, J. (2011). RSA compromise: Impacts on SecurID. Retrieved from http://www.secureworks.com/research/threats/rsacompromise/

Advertisements

Actions

Information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: