Engineering Secure Online Banking

On Tue, 8 Jul 2014 20:51 +0300 george [email protected] wrote:

Abstract — Taking into consideration the importance of security in online banking transactions, it is critical to reassess the efficiency and safety of using secure token devices such as the “Secure Key” device provided by most banks, and similar devices such as the DigiPass or other smart cards. The security requirements of such mechanisms need to become bulletproof to both inside and outside attackers, and considering the attacks that certain banking servers and users have fallen victims to, it would make sense to re-engineer some of the aspects of secure token generation, but also of the authentication transmission procedure. This document attempts to suggest some techniques which would add to the security of both procedures mentioned above, while also accounting for ease of usability and availability of both secure token and authentication to users. Tactical routines such as the Two-Factor Authentication, which is already being regarded into secure token implementations, is talked about, and the notion of additional measures such as Biometric Authentication and Out-Of-Band Authentication are being discussed. The ideas and suggestions mentioned need to be implemented on closed-circuit wide-scale test units, with formulated mock attacks and penetration tests, and algorithm robustness is to be inspected thoroughly.

I. INTRODUCTION

A security token, is most frequently implemented in the fashion of smart cards, key-fobs, mobile or computer desktop applications, in which security is achieved by generation of a number digit password, which is unique for each user at any given point in time. Usually, key-fobs such as the “Secure-Key” that is being used by HSBC bank for its customers’ internet banking transactions, uses a method of authentication called Two-Factor Authentication [1]. In Two-Factor authentication, generation of a user-unique password is considered as inadequate and the additional security step of including something the user knows, such as a PIN, is required. Such security tokens, use Public Key Cryptography Standards, as defined by RSA Laboratories which wrote the specifications [2]. In these standards one may find both algorithm specific and algorithm independent implementations.

Even though the secure token architecture has been broken by computer scientists in as little as 13 minutes, as described in [3], using a Two-Factor authentication method adds a significant amount of security. Two-Factor Authentication, consists of a token, i.e., a hardware device such as a dongle or a software such as a mobile application, combined with something the user knows, such as a simple Personal Identification Number. In Two-Factor Authentication, a key-fob, with a serial number known only to the bank’s systems, is issued to the customer. This key-fob, contains an internal clock which is pre-synchronized to the bank server’s clock. Prior to receiving a number digit password through a liquid crystal display, the customer is required to enter a Personal Identification Number (PIN) code, which has been registered with the bank and embedded on the key-fob authentication device. Upon issuing the correct PIN, the key-fob’s CPU uses the secret serial number of the device and the time on the clock to generate a number digit password which lasts for a set time-frame, usually up to thirty seconds or a minute, and then expires, both on key-fob and on server-side. When a banking transaction is to be made, the bank receives the calculated pass-code the user has inputed, and performs identical calculations on server-side, to determine if the password provided is the correct one. If it is correct, the customer transaction is granted, as explained in [4]. As expected, there are a number of vulnerabilities, even with using such a sophisticated protocol of authentication such as the secure token framework. These boil down to:

Losing or misplacing the Secure Key device: Users many times misplace their key-fobs, in places which they are accessible by others. In some cases, the devices have been acquired from naive users by social engineering methods. In any case, it has been difficult to convince users to safeguard their Secure Key devices at places which attackers cannot reach. For instance, many customers attach their key-fobs to their car key chains. Using a credit card and its PIN for activating the device via Two-Factor Authentication does not make it much more secure, as the PIN can easily be reseted by first locking the device, i.e., imputing the wrong PIN three times, and in turn following the directions for resetting the PIN, such as in this example provided by the Royal Bank of Scotland for DigiPass devices, found in [5].
Man in the Middle Attacks: In 2006, CitiBank was hit by an attack by Russian hackers. The hackers were performing Man in the Middle attacks against the bank’s secure token users, reported in [6]. In essence, they intercepted the seemingly secure communication between the users’ computers and the bank’s secure token servers. They would receive the users’ login and secure token PIN, while the user attempted login, and pose to the bank as the user. This alone called for better methods of secure authentication, and paradigms of multi-factor authentication started to be implemented, as more secure ways of generating a key. However, the problem still remains in that all information regarding the secure token and authentication steps are mostly transmitted in a single channel of communication.
Bank’s server hack: Most key-fobs which are used to generate a unique PIN code, base their algorithm on the secretive serial number of the device, and an internal clock used for disconnected synchronization between the fob and the bank’s servers. However, in order for the bank to be able to register the key-fob to one of their customers, the key-fob’s unique serial number needs to be registered in a database, along with the user’s personal details. This is done for reference reasons, in order for the server to know if the correct user is authenticating with their own key-fob. If a malicious hacker, is somehow able to access this database and download the serial numbers associated to specific users, the results would be catastrophic, as they would be able to calculate valid PIN codes in association to specific users, without needing physical access to the device itself.
RSA SecurID hacks: One of the most dangerous scenarios would be the case of hackers finding out the exact algorithms or source code of the SecurID protocol which is provided and developed by RSA. In fact, this has already happened in 2011 [7], even though the security response team of RSA stopped the attackers before they were able to download sufficient info from their servers to cause damage to the Two-Factor Authentication protocol. Also, it was deemed that the attack would not affect any of their customers. However, there were losses of 63 million dollars associated with the attack, as customer worries caused the company to lose credibility.

II. SECURITY GOALS

When speaking of security goals concerning security tokens such as the Secure Key used for online banking, the confidentiality, integrity and availability concepts come into play. They are of the highest importance, not only because of the users’ private information, but also because breaching these concepts would bear an economical disaster, not only for users, but also for the organizations which depend upon the above technologies to safeguard their services and offer security to their customers. It is important to note that usage of a secure key can not deter man in the middle or man in the browser attacks by itself. In order to prevent MitM attacks, other techniques have to be incorporated in not only the process of authentication between client and server, but also in the way or ways the client communicates with the server. This is where Out-Of-Band authentication comes into play, and it is a concept which shall be discussed later on. It has been proposed that the limited time-frame of thirty seconds to one minute given for security token validity, can actually prevent man in the middle attacks, as it does not allow enough time for a potential attacker to act upon intercepting a key, as proposed in [8]. However, as cross site scripting vulnerabilities (XSS) do exist in many web applications, they may allow an attacker to expose a vulnerability which would let them replay the token into the site and authenticate themselves automatically. This could be performed via an automatic script that would make many attempts on the banking site, thus allowing a replay of the token even in a short time frame. An attacker using this method would not be able to read the user password or security token PIN, but they would still be able to become authenticated and pose as the real customer. Even by utilizing secure HTTP connections in a browser, which all banks do, a man in the browser attacker could intercept requests from the victim’s browser and assume the victim’s identity, thus making the victim and the remote server to assume that the connection is secure between them. This is somewhat different from a cross-site scripting XSS attack. In an XSS attack, the perpetrator attacks the actual web application, listening in for connections from unsuspecting users. A man in the browser attack, even though it is still a MitM attack, it exploits the user instead of the application. This type of attack usually involves more steps, such as phishing attacks in attempts to trick users into unknowingly installing Trojan software on their computers. Once these type of malware are installed, the attacker can hijack the victim’s browser, and redirect them into secondary phishing sites, where automated scripts can collect a user’s password and security token PIN, while simultaneously they attempt authentication on the banking site by using the aforementioned information. As most normal internet banking users may be susceptible to such kinds of attacks, the effects of a Secure Key device and the security token mechanism does not provide full confidentiality as one would assume.

Communication between client and authentication service in Secure-Key authentication Re-engineering the way the Secure Key is communicated to the server, could significantly increase both the confidentiality and integrity of electronic financial information and transactions exchanged between a customer and the bank. This may be achieved by enabling more than one factor of authentication, with a multi-factor authentication paradigm, and also changing the way in which authentication is communicated to the server. This paradigm could include the user’s password, a security token such as a PIN generated by Secure Key or DigiPass devices, along with something the user knows, such as a security question, a custom PIN code, or incorporation of captcha image random character generation. Furthermore, confidentiality can be increased via encryption keys. Each user would need to receive an encryption key from the bank upon creating an online banking account. They could then, via a browser or mobile application, use this plugin to encrypt the login and transaction details, which would contain a username, password and Secure Key number digits. In return, once the bank’s servers receive this information, they will be able to confirm the identity of the customer by decrypting the information with the user’s public key. This will be used only for identity recognition and not for making money transfers or any other transactions. They encryption key may be included in the Secure Key or DigiPass devices, but such method should not be advisable as these devices could be lost, misplaced or stolen. Undertaking the endeavor of improving the security token concept, means to study additional measures to two-factor authentication by utilizing existing concepts and technologies, such as separating the levels of authentication and customer identity verification [9]. This means the combination of more than one authentication and identification methods such as incorporation of Knowledge Based Authentication, Biometric Based Authentication and Security Token Authentication.

III. DUAL-CHANNEL TWO-FACTOR AUTHENTICATION

It is true that combining two or more factors in authentication methods, enhances confidentiality and integrity. However it is also true that man in the middle attackers can bypass the security which these mechanisms offer, and listen in to secure connections via cross-site scripting attacks and man in the browser attacks.

OOB Authentication step-by-step Out-Of-Band Authentication, can be introduced alongside Security Token Authentication, in order to uthenticate a transaction via a separate secure channel. As described in [10], OOB authentication, aims to eliminate the threats posed by man in the browser attacks and malware such as trojans and phishing attacks. An example of Out-Of-Band Authentication can make the process easier to grasp. OOB authentication, attempts to authenticate transactions on two separate channels of communications. For instance, a password is used to access the internet banking system. Then, the user starts a transaction in order to transfer money to a secondary bank customer. To do this, the banking system will ask the user to authenticate the transaction via using a Secure Key device, which provides a short life pass code for the customer to use. However, in this case, everything happens in a single channel of communication, therefore the transaction authentication could possibly be intercepted. By introducing OOB authentication in the above scenario, the user would receive an automated phone call from the bank, asking them to enter on their phone’s keypad an additional PIN code. This way, the authentication is more secure, as an attack on such an authentication method would need to be extremely well orchestrated in order to work, and even in this case, it would prove to be very highly unlikely to happen, as an attacker would have to control many different factors, such as intercepting communication conducted by a Communications Authority.

IV. BIOMETRIC AUTHENTICATION

Biometric authentication comes in the forms of using human features unique to individuals, independent of their gender or age group. Such features include, but are not limited to, fingerprints, iris patterns and facial imaging. Biometrics can be used in order to authenticate a user to a locked system, or be combined with two-factor authentication to provide more secure means of authentication. There are some concerns when using biometric authentication. Credentials, such as fingerprints or iris patterns, are stored in a central database. These credentials cannot be revoked as normal passwords can, so it is important to safeguard such databases via means of encryption and maximization of physical access security.

V. COMBINATION OF AUTHENTICATION TECHNIQUES

The authentication techniques previously mentioned, may be combined in order to provide security at more than one levels. The types of authentication discussed, namely Object Based Authentication, Knowledge Based Authentication, Biometric Authentication and Out-Of-Band Authentication, can be integrated in online banking systems effortlessly, while at the same time providing ease of use. It is true that a mobile device already possesses all required technologies to provide to users a quick and easy combination of the above-mentioned methods of authentication. For instance, a front-face camera on a mobile phone may capture a facial image of the user while he is loading the banking application, temporarily storing the image in order to use it for Biometric Authentication once the authentication is sent. Secondly, a background service will generate a security token, provided to the user via a pop-up on the device’s screen. The user types his credentials and when a transaction is requested, the user is asked for the security token PIN. The user would then enter the PIN on the device, which would be encrypted via using the facial image as a key. In order to verify the transaction, an Out-of-Band authentication, automated phone call, will then take place, which will allow the bank’s customer to enter a new PIN on their phone’s dial pad.

VI. CONCLUSION

In this paper we have presented the various possibilities of authentication methods, while also providing an analysis, discussion, security evaluation and security concerns of each method. Specifically, we have investigated Knowledge Based Authentication, Object Based Authentication, and Biometric Authentication. Out-Of-Band Authentication was also discussed and used in a simplistic proposal towards increasing robustness and security of the multi-factor authentication paradigm for purposes of internet banking transactions. It has also been discussed that the introduction of mobile banking in addition to modern technologies such as front-face mobile cameras, and anywhere internet access via 3G networks can make the combination of the above discussed technologies a reality, while at the same time allowing users to get used to multiple steps and factors of authentication.

REFERENCES

[1] Retrieved from http://www.hsbc.co.uk/1/2/customer-support/online-banking-security/secure-key on February 15th 2012

[2] Retrieved from http://www.rsa.com/rsalabs/node.asp?id=2308 on February 15th 2012

[3] Retrieved from http://bits.blogs.nytimes.com/2012/06/25/computer-scientists-break-security-token-key-in-record-time/ on February 20th 2012

[4] National Authentication Framework Implementation Study. Retrieved from http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA514358 on February 22nd 2012.

[5] Man in the Middle Attack Against Two-Factor Authentications Retrieved from http://blogs.computerworld.com/node/2957 on February 25th 2012

[6] RSA Hit by Persistent Threat Attacks. Retrieved from http://www.computerweekly.com/news/1280095471/RSA-hit-by-advanced-persistent-threat-attacks on February 25th 2012

[7] The role of authentication tokens in preventing man in the middleattacks - RSA Security White Paper Retrieved from http://www.wordscape.com/michael-dowding-marketing-writing/white-paper-copywriting/RSA-Man%20In%20The%20Middle.pdf on February 26th 2012

[8] Authentication in an Internet Banking Environment Retrieved from http://digitallibrary.kcci.com.pk/bitstream/32417747/701/1/authentication_guidance.pdf on February 26th 2012

[9] Authentication in an Internet Banking Environment Retrieved from http://digitallibrary.kcci.com.pk/bitstream/32417747/701/1/authentication_guidance.pdf on February 26th 2012

[10] RSA Adaptive Authentication and Out-Of-Band Authentication Retrieved from http://www.rsa.com/products/consumer/datasheets/8898_OOB_DS_0212.pdf on March 13th 2012

Comments