2008 IEEE Congress on Services 2008 - Part I

A Model for Securing E-Banking Authentication Process:

Antiphishing Approach
Antonio San Martino, Xavier Perramon Universitat Pompeu Fabra asm@dp-securiy.com, xavier.perramon@upf.edu
Abstract This paper presents the authentication environment defined for securing E-Banking applications. The proposed method is part of a Phd Doctoral thesis aimed at defining a model for secure operation of an Internet Banking environment, even in the presence of malware on the client side. The authentication model has been designed to be easily applicable with minimum impact to the current Internet banking systems. Its goal is to be resistant to the nowadays too frequent phishing and pharming attacks, and also to more classical ones like social engineering or man-in-the-middle attacks. The key point of this model is the need for multifactor mutual authentication, instead of simply basing the security on the digital certificate of the financial entity, since in many cases users are not able to discern the validity of a certificate, and may not even pay attention to it. By following the rules defined in this proposal, the security level of the Web Banking environment will increase and customers trust will be enhanced, thus allowing a more beneficial use of this service.

a logical model of the service. Next, the multifactor mutual authentication environments are enumerated. Finally, in the conclusions section the achievements are summed up. The specific novelty of this work is the mutual authentication method, which if correctly implemented avoids many threats such as phishing, pharming, man in the middle attacks and identity theft. II. STATE OF THE ART Many financial institutions today offer some sort of web banking services to their customers, with various levels of functionality. Information protection in these services is also implemented with different techniques, and some may be more vulnerable to potential attacks than others. At a general level, most information security management systems follow the directives specified in the ISO/IEC 27001 standard [1]. This specification provides general rules for the selection of appropriate security controls to protect information assets. At the specific level of Internet banking security, there is not an established standard that all Web Banking services follow, but there are some sets of guidelines oriented to particular environments. Examples of these are the Payment Card Industry (PCI) Data Security Standard (DSS) [2], and the VISA standards on payments security. In addition, various governmental organizations publish their own guidelines, as e.g. in the case of America, the electronic banking guides issued by the Office of the Comptroller of the Currency (OCC) [3], the ebanking examination procedures issued by the Federal Financial Institutions Examination Council (FFIEC) [4], or the rules issued by the Federal Trade Commission (FTC) [5]. Research works have been published addressing different aspects of Internet banking security [6,7,8,9]. Our work is aimed at presenting a comprehensive approach to the problem of security in web banking applications. In this paper just a part of the entire work is presented, namely the authentication process. III. LOGICAL MODEL

I.

INTRODUCTION

A number of techniques and standards have been developed for providing information security in different applications, but currently there is no official standard for a methodological approach to web banking security. However, there is an increasing number of new attacks and viruses against web pages of financial entities[13], such as phishing and pharming frauds, that must be addressed in order to guarantee customers trust in web banking services. No standard exists in order to address and manage phishing and pharming attacks. The proposed multifactor mutual authentication process presented here allows to detect and then address these last two threats. Our authentication model works in a secure way also in these extreme cases. The goal of the work, which has been conducted in collaboration with several financial entities in Spain and Italy, is to specify a methodology for securing Internet-based banking applications. In the development of this work a number of different Internet Banking scenarios have been considered, and specific Internet Banking threats have been included in the risk analysis. Currently we are developing a prototype in order to demonstrate the effectiveness of the proposed solution. In this paper, after a brief overview of the state of the art in Web Banking security, the bases for our proposal are presented:

Our approach to web banking security is based on a logical model comprising the following elements:

978-0-7695-3286-8/08 $25.00 2008 IEEE DOI 10.1109/SERVICES-1.2008.32

251

Web browser and customer network Internet Bank server and private network Of these elements, the least configurable one is Internet, so we will consider that it has be taken as it is, with no additional security measures other than those that the network itself may provide. On the other hand, the level of security is critical in the other two elements. The basic idea would be to be able to work in a secure way on a critical environment and for this reason we will not make any assumption on security restrictions or requirements on the client side. In the initial state the user and the bank server are mutually untrusted, and the appropriate security measures must be taken in order to give confidence to both parties. The goal is to provide security in the above mentioned environments: customer bank network, Internet, and bank server, and to be immune to threats, such as many viruses and Trojan horses, that affect the customers network. IV. N FACTORS MUTUAL AUTHENT ICATION 1) N factors Mutual authentication process environment Web banking systems, as any other web application, use HTTP for data transfer. Regarding HTTP, all communications must be secured with the SSL/TLS protocol (i.e. HTTPS), and it is strongly recommended to use the POST method for sending data wherever possible. The best authentication method is mutual authentication as it avoids, when carried out in a proper way, phishing and pharming attacks. Such authentication process comprises key interchange, server authentication, and user authentication. A part of our work has consisted in defining security requirements for mutual authentication, and every detail has been taken into account and included in the risk analysis; any non-compliance of the defined rules will make the application vulnerable and the purpose of mutual authentication will fail drastically. The goal of any authentication method is to work reliably under adverse security conditions in a hostile environment, and in particular it must be resistant to man-in-the-middle attacks. Thanks to this model, the more sensitive authentication factor will be protected from theft. This system is able to provide the maximum and more secure authentication method. The authentication process will involve two parts: for easy understanding we will call one user and the other server. In order to consider all possible situations tree authentication models have been defined. Each of these models is based on a different hypothesis. All three models can work with 3 authentication factors. The three factors are: something you have, you are, or you know. Three factors authentication is the highest authentication level.

a) Basic Model: This model is based on the hypothesis that only one of the parts involved in the authentication process is the potential hijacking victim. For this reason it is required that the potential hijacking victim (eg: Server) must be first authenticated. In this authentication model all authentication factors will be requested and evaluated in the same request. This model is faster than factor protection model and than factor protection mixed model. The basic model, showed in Figure 1, is composed of two steps, first the user require for a particular server authentication values. If previous step has successful result, and then the server has been correctly authenticated, then the user will provide his credentials.

Figure 1: Basic Model

b) Factor protection model This model is based on the two hypotheses: 1. both parts, involved in the authentication process, are equally potential hijacking victims. 2. at least one authentication factor is more sensitive than others. Under these hypotheses we want to save the most sensitive authentication factors. In this case there is not any requirement about who will be authenticated first. Here the restriction is

252

that each part must verify in a sequential order factor by factor. The factors are evaluated from lowest to highest factors sensitive level. The first part will verify authentication of one factor of the other part and then this latter part will verify an authentication factor of the first part. In this way the most sensitive factor will be protected by the verification steps of the previous authenticated factors. Only if all previous authentication steps have successful results will it be possible to evaluate next authentication factor. In Figure 2 we show the process, it starts requiring an authentication factor for one of both entities, the server in the example, when correctly authenticated, the process follow authenticating one factor of the other entity (the user in the example). This process will be repeated for all authentications factors required for completing the entire authentication process. Factor protection model can be combined with basic protection model.

authentication factor. No restrictions have been defined for other potential factors involved in the authentication process. This process is faster than Factor Protection Model as it allows the simultaneous evaluation of more than one factor. d) A RealCcase Implementaion In this explamle represented graphycally in Figure 3 we propose a particular authentication process implementation consisting iin the combination of basic model. In this case the user first require for a particular Server Authentication and if the response is correct, then the user provide his credentials acconcording to the authentication request for the user by the Server.

Figure 3: Real Case Implementation At continuation we present security requirements for elements intervening in the authentication process represented in Figure 3. If proposed requirements are not respected, then the process will be vulnerable. ID_CARD: Length=at least 10 digits Char Space=[a-zA-Z][0-9] Generation: Random Req_Auth: Length=at least 3 digits Char Space=[a-zA-Z][0-9]

Figure 2: Factor Protection Model c) Mixed Factor Protection Model This model is based on the hypothesis that both parts involved in the authentication process are potentially hijacking victims. Another assumption is that all authentication factors have the same sensitive level. This model is a combination of both previous cases. In this case at least one factor must be evaluated after the successful evaluation of another

253

Generation: Random One Time Password Auth_Code: Length=at least 8 digits Char Space=[a-zA-Z][0-9] Generation: Random UserPredefinedObject: Type: Object, image, interface appearances, logo, Char Space=[a-zA-Z][0-9] Generation: User chosen USR_ID: Length=at least 10 digits Char Space=[a-zA-Z][0-9] Generation: Random USR_KEY_DER: MD5(SRV_RND_KEY+USR_KEY) USR_KEY: Length=at least 4 digits Char Space=[a-zA-Z][0-9] Generation: Random USR_OT_PWD: Length=at least 5 digits Char Space=[a-zA-Z][0-9] Generation: Random One Time Password CONCLUSIONS Our objective was to propose an authentication method resistant to phishing, pharming and Man in the middle attacks. We focused specifically on the E-Banking scenario. The goal has been reached by basing the protection on the mutual authentication process, of which each detail has been accurately studied. As mentioned, the main proposed novelty is this mutual multifactor authentication process, which is responsible for making the financial entity system highly invulnerable and immune to phishing and pharming attacks, and obviously also to identity theft and man-in-the-middle attacks. In addition, security is provided in front of a compromised client environment, like virus or spyware infections on client

side, as such malware could be able to steal the banking customers account access information. In order to take into account all security topics not covered by the mutual multifactor authentication method, a number of security polices have been defined in this research project. These policies are very important in order to develop a secure E-Banking platform. Specific security policies have not been explained in this paper for obvious reasons. This authentication model is going to be simulated in order to demonstrate its robustness. ANTONIO SAN MARTINO PACE Antonio is currently the Chief Security Officer of a mutinational enterprise that provides remote control and remote network administration solutions. Antonio is also a PhD candidate with more than 6 years of experience on information security (information security researcher, system administrator, IS auditor, European projects leader and currently Chief Security Officer). REFERENCES
[1] ISO/IEC 27001 (2005): Information technology Security techniques Information security management systems Requirements [2] http://www.pcisecuritystandards.org/ [3] http://www.occ.treas.gov/ [4] http://www.ffiec.gov/ [5] http://www.ftc.gov/ [6] C. Ohaya: Managing phishing threats in an organization. In: Proceedings of the 3rd annual conference on Information security curriculum development (2006) [7] K. B. Bignell: Authentication in an Internet Banking Environment; Towards Developing a Strategy for Fraud Detection. In: Proceedings

of the International Conference on Internet Surveillance and Protection. IEEE Computer Society (2006)
[8] A. Segev, J. Porra, M. Roldan: Internet security and the case of Bank of America. In: Commun. ACM 41, 10 (1998)

[9] M. Nilsson, A. Adams, S. Herd: Building security and trust in online banking. In: CHI'05 Extended Abstracts on Human Factors in Computing Systems. ACM Press (2005) [10] http://www.owasp.org/ [11] http://www.sqlsecurity.com/FAQs/SQLSecurityChecklist/tabid/57/Default.aspx [12] www.eccouncil.org/CEH.htm [13] http://www.hispasec.com/laboratorio/banking_trojan_capture_video_clip.pdf [14] http://cws.internet.com/article/3291-.htm [15] http://news.zdnet.co.uk/security/0,1000000189,39259632,00.htm [16] http://www.theregister.co.uk/2005/02/09/banking_trojan/ [17] http://www.theregister.co.uk/2004/11/12/banker_trojan/

254