Need for Risk Based Authentication and how it works

3 11 2011

Online money laundering has been one of the major concerns of financial institutions for more than a decade. Although it is the customer’s money which gets stolen , many a times institutions cover for the customers money instead of losing reputation because of such  frauds. If money is such a valuable asset,  are we not able to build a fool proof system or cannot we have a the most secure system  to protect it ? Well , the answer is it is not impossible but it is not practical . Lets us discuss below as why one of  most secure system was not necessarily the most desirable one.

We have come across/experienced  different kinds of security while dealing with online banking . Typically we identify ourselves with our user names and authenticate with just our password . Also we have come across situations where we have to answer some secret questions ( ‘Whats your mother maiden name’ , ‘Color of your first car’ ) or in some cases enter a random number(technically its not just a random number) displayed on the fob key . In some cases we receive a secret phrase to our mobiles or to our email and we are asked to enter the same.

Well we could enumerate numerous such methods . But lets see  which of these is the most secure way of authenticating users. Some of us might say random number in the fob key , some might say passwords and we could have varied opinions. Could we go to the extent of combining the strength of all of the above methods i.e each time you want to access online bank or to do some transaction , user could authenticate using all the methods – fob key , password , a secret phrase and which ever secure way we could think of .Clearly the trade off here is the usability.

Online banking did go through a phase where just having the most secure system was not doing much good . In the initial stages we had single factor authentication. User was asked to authenticate using just his password . Gradually as  online banking got more limelight ,as there was more money  online slowly the number of people who wanted to steal also increased . Banks wanted to be smarter and started using 2-factor authentication ( authenticate using two different methods Eg password + secret question ) . As banks saw the need to make their assets more secure they resorted to multi-factor authentication , having the customer go through multiple levels of security checks and to be dead sure that they have a genuine person who is trying for access . This proved to be effective in securing money , but the trade off here was the usability.

Consider a situation where you have to spend 5-10 mins authenticating to the bank just to buy a 20$ T-shirt online . There were lot of cases where merchants  reported that users used to add things to their shopping cart and then quit in the middle when banks made them go through multiple authentications to transfer money to the merchants. This led to a loss of money for the merchants and soon banks had to find out better ways of dealing with things .  These factors led to a new way of authentication called risk based authentication (RBA).

The idea behind the RBA is less than 1% of the transactions ( some security experts might even say less than 0.1% ) are fraud . So every user should not be penalized because of one or two fraudulent transactions out of thousands. RBA achieves this by analyzing or identifying those transactions which seem to risky and to put more layers of security only when it  suspects some fraudulent activates . So typically users will have single factor authentication . If the RBA system suspects that something is fishy in the transaction only then it recommends for more layers of security .

Lets talk of a  simple example to understand how RBA works . Say a user who holds a account in ‘Bank of America’ . Say this user usually transacts from Pittsburgh and deals with 100-200$ each time he transacts online . Each time user transacts online through the banks website ,  RBA which runs behind the scenes ,  learns about the user . It maintains a profile of the amounts with which he deals with , his ip address and many other information . Typically it would authenticate him with just his password .Say now , someone tries to login into his online account from Nigeria and tries to transfer 5000$ from his account . This is where RBA plays a vital role. Now that it knows that usual transaction style of the user , RBA would suspect a fraud here . Based on the level of suspicion stronger layer of security would be recommended . Having got this recommendation, banks might ask the user to answer some secret questions or might send a one time password to his mail/phone . If the user could pass through these stronger security layers , it is less probable that it is still a  fraudulent transaction. Not all the users/transactions would go through these additional security checks but only the suspicious ones.

By  analyzing the  risk of each transaction and by putting in a more stringent security checks for riskier transactions , RBA systems strike a good balance between security and usability of the system . To analyze a riskiness of a transaction they take account many criteria’s such as users ip-address , cookie information , device finger print of the system , his transaction style etc. The core component of a RBA system is a risk engine which can analyze the risk of each transactions . The risk engine is a self learning , dynamic system which provides better results when it has more information about the user.   The success of these systems are measured by the number of fraudulent transactions detected out of every 100 transactions . These systems have been backbone of many financial institutions in the past years.

RSA is one such company which has been fighting frauds using RBA . RSA’s Adaptive authentication has been serving as a backbone for many banks and financial institutions . RSA has also built a cross institutional repository of fraudulent information called as e-fraud network which enhances fraud detecting capabilities of Adaptive authentication and there by saving millions of dollars worth of online fraud.





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/