International Journal of Computer Information Systems, Vol. 3, No.

4, 2011

TWO FACTOR AUTHENTICATION USING SECONDARY WEBSITE

Arunkumar R
Department Of Computer Science Engineering Hindustan University Chennai, India arueng@gmail.com

Narendrakumar S
Department Of Computer Science Engineering Hindustan University Chennai, India narendrakumarorange@gmail.com

vishnu chaithanya L
Department Of Computer Science Engineering Hindustan University Chennai, India mailvishnu03@gmail.com

Chrystal Amutha D
Assistant Professor Department Of Computer Science Engineering Hindustan University Chennai, India chrystalamutha@gmail.com

Abstract- In recent years Internet banking services has faced many attacks from simple credential stealing attacks to advanced content-manipulation attacks by hacking software from client end-devices. This paper presents a unique approach of secure beneficiary confirmation on a two factor authentication using secondary website. The proposed system involves as a software token for One Time Password generation. The generated One Time Password is valid for only a short user defined period of time. This method makes difficult for hackers to hack the password. The proposed method has been implemented and tested. Keywords: Network Security, Internet Banking

1. Introduction Internet banking has become widely popular in the modern world because of its wide array of benefits. Net banking offers more flexibility to do financial transaction on any day irrespective of the time. In todays fast life, people are much stressed out because of their work pressure and net banking offers them peace of mind as they can pay their bills, book their tickets, do online shopping, etc. Net banking gives very easy way to do any transaction over the net and highly secured websites takes care. Financial transactions done over Internet are supposed to be done in real-time and have become extremely sensitive. After this execution, they become very hard to recover. At the time of writing, modern Internet banking offering payments to freely selectable beneficiaries, follow the general approach of establishing at login a strongly Authenticated and encrypted communication channel between the client end-device and the banks server. Once established, the

reliably identified user can either work freely with his or her account or perform all kinds of transactions, or is requested to additionally authorize transactions with a transaction-independent Transaction Authorization Number (TAN). In recent years, the authentication methods used for establishing such channel or authorize such transactions have been constantly revised and advanced with regards to commonly observed attack vectors; the main goal being to thwart attacks focusing on credential-stealing, for instance, via phishing or manin-the-middle (MITM) [1,2,3]. However, in the mean time, more sophisticated attacks specifically, silently manipulating the input and output on the client end device by means of malicious software or malware (MSW) have surfaced [4]. Some of these new attacks are built upon a combination of MSW and MITM if, for instance, MSW controls the web browser towards enabling or facilitating a subsequent MITM attack. Others exclusively use MSW towards silently manipulating transaction data submitted through or displayed in the web browser. Both of these attacks are commonly referred to as man-in-the-browser attacks [5]. In the light of such advanced content-manipulating attacks, in essence, information either sent to or keyed in on the client end-device can no longer be fully trusted to reach that device or the banks server without any relevant changes. Therefore, the approach of relying only on user authentication and/or transaction authorization had to be considered insufficient for protecting sensitive transaction data. Many regulators reacted [6, 7, 8, and 9] and forced their banks into providing customers with appropriate complementary

October Issue

Page 173 of 179

ISSN 2229 5208

International Journal of Computer Information Systems, Vol. 3, No. 4, 2011 security means. Transaction dependent authentication was soon identified as a potential means to thwart the new type of attacks, but only if the process for confirming the sensitive content of transactions could effectively be shielded from the client end-device by moving it to a trusted device not exposed to MSW. In this paper, we discuss such security solutions and point out crucial success factors that eventually determine if the user is able to intuitively understand his or her responsibility and due diligences and therefore can also be deemed liable to take advantage of the new protection mechanisms at his or her disposal. In security relevant aspects, we also consider business relevant properties such as convenience, mobility, integration, administration, and last but not least costs. This finally leads us to an approach for beneficiary confirmation, enhanced with white list management and two trusted device implementations that offer a unique combination of properties found to best match the business and customer expectations of a large bank. 2.3 Software Attacks: The main focus of this paper is software attacks, as they must be considered the most common and most threatening attack vector for several reasons. Firstly, software attacks can be launched easily from remote against a very large number of users, for example, by spreading a virus via email or via infected web sites. Research shows that the latter approach, also known as drive-by infection, is gaining large popularity at the time of writing [4]. Secondly, the effort required to implement software attacks is constantly decreasing due to the fact that the required knowledge and easy to use tools are available from the Internet at very low costs and users have problems with keeping their software at the latest patch level [10]. Lastly, software attacks are, if possible at all, very hard to trace back, as the initiators typically hide behind botnets and server infrastructures hosted in various foreign countries and governed by various different jurisdictions. Such software attacks can be further categorized as follows: Credential-stealing attacks Channel-breaking attacks Content-manipulation attacks Credential-stealing attacks aim at fraudulently gathering a users credentials, for example, via MSW or by tricking the user into voluntarily revealing them, for instance, to a fake login page. Channel-breaking attacks, aim either at intercepting messages between the client end-device, typically a personal computer (PC), and the banking server or at taking over the client session as a main-the-middle. While these two attack classes along with relevant authentication methods have been discussed in depth in [1], this paper further focuses on content-manipulation attacks targeting the transaction data entered via the client PC. This can be considered the most advanced attack vector, which renders precautions used to thwart the other two attack classes, for instance, short-time passwords generated by hardware tokens or mutuallyauthenticated SSL/TLS connections ineffective. Content-manipulation attacks are typically implemented by means of MSW seeded on the client PC. Despite the fact that users protect their PCs by maintaining firewall and anti-virus software, in practice, MSW finds its way to infect PCs by exploiting either user inadvertence or constantly reappearing software deficiencies. Experience shows that it is impossible to reliably and lastingly protect software running on todays client hardware and operating systems, lacking trusted computing support, by means of other software running on the same platform [11]. Momentarily observed effectiveness of such software

2. Relevant Attacks The attacks against Internet banking services can be classified into three main categories: Physical attacks Social attacks Software attacks 2.1 Physical Attacks: This kind if attacks are steal tokens, crack chip cards or issue fake devices. Such attacks are considered out of scope for this paper, since they cannot be easily launched against a large number of users and can be traced using standard investigative methods. Nevertheless, we recommend that user credentials such as cryptographic keys shall be reasonably protected against physical attacks, for instance, by storing them on tamper resistant smart cards secured by a PIN code. 2.2 Social Attacks: By convincing users to perform certain actions, for example, to authorize a transaction to an unknown beneficiary or to divulge secret information such as their authentication credentials to an unknown third party. To our knowledge, there is no technical solution that reliably thwarts such attacks without assuming a certain degree of user due diligence. Therefore, in this paper we focus on providing the user with the technical environment that enables him or her to easily comply with due diligence rather than trying to eliminate these social attacks in the first place.

October Issue

Page 174 of 179

ISSN 2229 5208

International Journal of Computer Information Systems, Vol. 3, No. 4, 2011 must therefore be interpreted with due precaution and as such be considered more consequence of its proprietary nature than of any specific hardening [12].From a long term perspective it is wiser therefore to assume that a users PC, which cannot be securely rebooted for e-banking and that is regularly used for browsing and e-mailing over the Internet, will continue to be exposed to MSW able to take over full control. Under this assumption, an attacker does no longer need to steal authentication credentials or break into the secure channel established between the users PC and the banks server, but will rather take direct advantage of MSW to silently submit or modify transaction data while the genuine user is connected to the bank. However, in addition to the security aspect, other aspects can be equally important for the applicability and success of a solution. Therefore, in this paper we also consider the following additional business relevant solution properties: Integration: The solution shall integrate well with existing infrastructures. This includes client- Side hardware and Software, communication protocols, and server-side requirements. Cost: Overall costs shall be low to qualify for high volume deployments, for instance, in retail banking. 3. Possible Solutions The majority of Internet banking services offering free selection of beneficiaries does not satisfy the security requirements. In particular, they do not provide a technical environment that allows a user to reliably detect and thwart content-manipulation attacks carried out by means of MSW. For instance, softwareonly solutions or trusted device solutions, without secure display, offer some transitional security, but no reliable technical resistance against such attacks. by using one time password(OTP) this kind of attacks can be avoided. Only a few solutions potentially Providing the desired security level have surfaced .All of them comply with the inevitable requirement to confirm sensitive transaction data via a separate trusted device, independent from the display and keyboard of the potentially Infected client PC. What differs is whether or not the device is physically connected to the client PC and how data is entering and leaving the device. For example, transaction details to be confirmed might be sent to the device automatically via a Universal Serial Bus (USB) connection or might have to be entered manually by the end user. Similarly, the result of the confirmation process, typically a digital signature or a Transaction-dependent Authentication Code (TAC), might be retrieved either automatically or manually. The way how communication with the security device is implemented also has significant impact on afore mentioned solution properties. Table 1 lists the most familiar of these solutions, data input/output methods, and some property ratings. Solution A: The transaction details are not entered manually but transmitted within an encrypted flickering image such that a trusted device can read it via an optical interface from the client PC screen. For that the user must place a special trusted device equipped with optical sensors and a decryption key firmly in front of the flickering image onto the computer screen. Transaction details to be verified and a TAC to be copied by hand are both displayed after local decryption on the trusted device. This approach somewhat increases convenience while the interaction pattern may appear unfamiliar, could require fine motor skills from the user and sometimes also comes with dependencies from screen size and resolution. Furthermore, security is fine, but integrating the flickering image functionality on the server side requires changes to the banking service and the need for an optical interface increases costs.

Solution B is based on a standalone TAC generator device not connected to the PC or any network, as described in [1] or defined by the EMV Chip Authentication Program (CAP) for secure credit card payments over the Internet [14]. Such devices either have built-in cryptographic keys or provide a smartcard interface such that, for instance, EMV compliant credit/debit cards can be inserted. While security is fine, the user has to manually enter the transaction details and PIN via a built-in keypad. The device then generates a TAC that needs to be manually copied to the web browser. Obviously the device is not exposed to MSW, as it is not connected to the PC. But for the same reason, it can also neither be remotely configured nor updated. Furthermore, manual interaction decreases convenience and renders the approach impractical for frequent users, whereas other properties like the low device costs make it an interesting option for occasional users. Solution C can be considered a variation of solution B where the transaction details are not entered manually. It makes use of the users mobile phone as a separate end device and the short message service (SMS) available in mobile phone networks as an independent communication channel to that end device. A servergenerated TAC is sent to the users mobile phone via SMS along with the details of the transaction previously placed over the Internet. The user can then verify the transaction details on his or her phone and approve them by copying the associated TAC to the web browser.

October Issue

Page 175 of 179

ISSN 2229 5208

International Journal of Computer Information Systems, Vol. 3, No. 4, 2011

roperty/S olution A B C D E Input Output Convenience Cost Separate physical device Yes Yes Yes Yes No

Auto Manual Auto Auto Manual

Manual Manual Manual Auto Manual

++ + ++ ++ +++

Medium Low Medium High Low

The generated OTP is sent to their secondary website account. They have to enter this generated OTP in their bank account to access further. By this way the customers need not to carry mobile or any other devices. Even though, all the above solutions having advantages, but also reveal some shortcomings, specifically when facing large scale deployments. From a user perspective, and thus critical for the overall success of such a solution, security, convenience and external physical device can be considered the most important properties .even in OTP(One Time Password) using mobile technique needs mobile. But here we are going to provide e-Transaction guarantees in asynchronous system with no assumption on the accuracy of failure detection in this method customers no need to carry any mobile or external physical device. Therefore, in this paper we present two solutions that clearly improve the respective properties of the solutions listed in Table 1. Solution A needs external device, high cost and has some difficulty to bring everywhere. The second is based on the low cost Solution B augmented with comprehensive server-side white list management to improve user convenience, specifically for occasional users. The theird can be considered a variant of the highly .Solution E has more convenient for users than other solutions. Because it does not require any external physical device, low cost and more convenient. Here we are going to discuss about solution E which is based on OTP algorithm. 4. Design and Implementation In this paper, we are going to implement solution E using OTP. This proposed system is Secure and convenient. Here OTP algorithm is used. This generated OTP is sent to secondary website. This OTP (One Time Password) needs to be entered in primary account to access. 4.1 OTP Algorithm OTP (One Time Password) algorithm is going to be implemented in this paper. In order to secure the system, OTP algorithm is used. Therefore, Its very important to develop a secure OTP generating Algorithm. OTP is a password that is valid for only one login session or transaction. OTP is based on randomness. OTPs avoid a number of shortcomings that are associated with traditional (static) passwords. The most important shortcoming that is addressed by OTPs is that, in contrast to static passwords, they are not vulnerable to replay attacks. This means that, if a potential intruder manages to record an OTP that was already used to log into a service or to conduct a transaction; he or she will not be able to abuse it since it

Table 1. Contemporary Transaction Authentication Solution and their properties In contrast to the other proposed solutions, the security prerequisites for this approach Already raised some concerns, due to the increasingly vanishing independence between mobile and Internet communication channels and the potentially inappropriate customer authentication used by mobile service providers before issuing secondary SIM cards or forwarding SMS messages to a different number [15]. While the effort required to integrate an SMS service is acceptable and the mobility of the solution is good, the improved user convenience remains somewhat limited, as the TAC still needs to be copied by hand. Further drawbacks are that the SMS delivery is not highly reliable in all countries, e.g. US, the SMS service generates significant recurring costs, and involved network operators can trace the messages. Solution D makes use of yet another trusted device, a secure smart-card reader equipped with a display and keypad and connected with the PC via USB, as specified for example by the FINREAD reader standard.Transaction data is transmitted automatically from the web browser to the smart-card reader. The user inserts his or her smart card into the reader device, possibly unlocks the card by entering a PIN code, verifies the transaction details on the trusted display, and finally confirms sensitive transaction data via the trusted keypad. Unfortunately, proposed devices are typically quite bulky and require specific device drivers and possibly additional software to be installed on the users PC. Therefore, these solutions are less mobile and often also face problems in working with different operating systems and web browsers or try to overcome this with an own browser inducing the need for bulky security updates. Last but not least, these devices require an effective shielding from the client PC and are rather expensive. Solution E: In order to improve security in the online banking, the generated OTP (One Time Password) must be hard to guess, retrieve, or trace by hackers. So it is difficult to eves dropping. Therefore, its very important to develop a secure OTP generating algorithm. Several factors can be used by the OTP algorithm to generate a difficult-to-guess password.

October Issue

Page 176 of 179

ISSN 2229 5208

International Journal of Computer Information Systems, Vol. 3, No. 4, 2011 will be no longer valid. On the downside, OTPs are difficult for human beings to memorize several factors as it is based on OTP algorithm to generate a difficultto-guess password. Username: this is required to access secondary website and to know generated One Time Password (OTP) PIN: This is required to verify that no one other than the user is using the secondary website to generate the users OTP. The PIN together with the username is data that only the user knows. So OTP cannot be generated correctly without Knowing the users PIN. This Personal Identification Number (PIN) knows only by user. Without username and the PIN that secondary website cannot be accessed. They are just used to generate the OTP and discarded immediately after that. So PIN is hard to guess for hackers. In order for the PIN to be hard to guess or brute-forced by the hacker, a minimum of 8-characters long PIN is requested with a mixture of upper- and lower-case characters, digits, and symbols. Hour: Makes the OTP generated each hour to be unique. Year/Month/Date: OTP can be generated using last two digits of year month and date. Day: It makes the OTP set unique to each day of the eek. Minute: This would make the OTP generated each minute to be unique; hence the OTP would be valid for one minute only and might be inconvenient to the user. An alternative solution is to only use the first digit of the minute which will make the password valid for ten minutes and will be more convenient for the users; ince some users need more than a minute to read and enter the OTP. 4.2 Secondary website This secondary website is used to know generated OTP (One Time Password) by user. This user name is not same as their online bank account user name. After entering user name and password the page will be opened to know generated OTP. After entering user name virtual key board is opened to enter password as shown in table 2. If we use key board there is a possibility to store password using malware software. Table .2 secondary website with virtual keyboard:

After successfully entering into secondary website user can see generated OTP and have to enter this OTP in teir bank account to access. 4.3 Database Design: A database is needed on the server side to store the clients identification information such as the first name, last Name, username, pin, password and secondary website. The password field will store the hash of the 10 minute password. It will not store the password itself. Should the database be compromised the hashes cannot be reversed in order to get the passwords used to generate those hashes. Hence, the OTP algorithm will not be traced. 4.4 Server Design A server is implemented to generate the OTP on the organizations side. The server application is multithreaded. The first thread is responsible for initializing the database and listening the client requests. The second thread is responsible for verifying secondary website user name and password, and generating and sending the OTP. A third thread is used to compare the OTP entered in online bank account using the connection-less method. In order to setup the database, the client must register in person at the organization. 5. Beneficiary Confirmation After entering into primary website (bank website) using OTP generated in secondary website, user can access and go for payment. Fraudulent payments are a rather intuitive approach but, as with most intuitive things, challenges start to surface only when it comes to implementation. The two main

October Issue

Page 177 of 179

ISSN 2229 5208

International Journal of Computer Information Systems, Vol. 3, No. 4, 2011 questions to be answered are: (a) What should be displayed? (b) When should it be displayed? Although practice can differ from one country to another, we made the observation that the success of a payment order often does not depend on the correctness of the specified beneficiary name and/or address, but solely on the correctness of the specified beneficiary account and/or payment reference number. For the payees bank it is mostly impossible to validate the beneficiary name provided together with a beneficiary account, whereas for the beneficiarys bank, as long as the beneficiary account and/or payment reference number allow for an unambiguous crediting, the additionally provided information, like the name and address of the beneficiary, are mostly not taken into consideration. This shows that towards an effective beneficiary confirmation, it is essential to identify what uniquely determines the beneficiary of a transaction, depending on the beneficiarys bank and the type of payment, and have the user check and confirm only this. Nevertheless, many implementations of such extra confirmation steps seem to miss this crucial aspect as exemplified in Table 3. By displaying too many transaction details, the user is fooled in approving a transaction, Irrespective of the correctness of what matters (the beneficiary account) being blinded by the correctness of what does not matter (the beneficiary name). Therefore, we propose to only ask the user to confirm the beneficiary account or payment reference number, if this has been verified to eventually determine the beneficiary. they already confirmed before. It is therefore also crucial for the effectiveness of beneficiary confirmation to ask for a confirmation only when the beneficiary is neither globally trusted by the bank nor known to be trusted by the user. 6. Practical Results and Discussion The server was implemented using Java and another website was created using Java. An Oracle 10g was used as a database. When online banking account is opened OTP (One Time Password) is sent to secondary website. This OTP is generated by server side. Now user has to enter OTP in their primary website to do further access. User cannot enter into their account without entering OTP. An experiment was done to check the chances of generating two identical hashes for two different users, i.e. generating a hash collision. In this experiment, the database was filled with information for ten fake users. The generated OTP was set to be 14 characters long. The OTP can consist of upper/lower-case characters, digits, and symbols, yielding a total of 4.9E+91different possible combinations. For each of the ten users, 200,000 OTPs were generated and compared; a total of 1 million OTPs. All million OTPs were unique.

7. Conclusions Now days, single factor authentication (passwords) is no longer considered secure in the internet and banking world. Two factor authentications are more secured than single factor .Two factor authentication has recently been introduced to meet the demand of organizations for providing stronger authentication options to its users. In most cases mobile is used to send OTP. In this case a customer needs to carry their mobile. There might be also problem if delay in receiving message or mobile is missed. So customers not able to access their online account. In some banking hardware token is given to each user for each account. This increasing number of carried tokens and the cost the manufacturing and maintaining them is becoming a burden on both the client and organization. This paper focuses on the implementation of two-factor authentication methods using secondary website. This method has been successfully implemented and tested, and shown to be robust and secure. The system has several factors that make it difficult to hack. The only thing new website needs to be created to receive OTP.

Table 3. Displayed transaction details to be confirmed Beneficiary Name: Beneficiary Account: Transaction Amount No: Confirmation Code: Beneficiary Contact no: Beneficiary Address: Transaction Date: Arvind 1234-5678-9000 10000 INR 123456 9876543210 20,private street 23-sep-2011

Another important aspect to take into consideration is the de facto increase in negligence, if users are asked for confirming things too often or for confirming things

October Issue

Page 178 of 179

ISSN 2229 5208

International Journal of Computer Information Systems, Vol. 3, No. 4, 2011

AUTHORS PROFILE References

[1] A. Hiltgen, T. Kramp, T. Weigold, Secure Internet Banking Authentication, IEEE Security and Privacy Journal, vol. 4, no.2, March/April, 2006, pp. 21-29. [2 ]Aladdin Secure SafeWord 2008. Available at http://www.securecomputing.com/index.cfm?skey=1713 [3] A. Medrano, Online Banking Security Layers of Protection, Available at http://ezinearticles.com/?Online-Banking-Security Layers-of-Protection&id=1353184 [4] B. Parno, C. Kuo, A. Perrig, Phoolproof Phishing Prevention, Proc. Financial Cryptography and Data Security, Springer LNCS, vol. 4107, 2006, pp. 1-19. [5] B. Schneier, Two-Factor Authentication: Too Little, Too Late, in Inside Risks 178, Communications of the ACM, 48(4), April 2005. [6] C. Ronchi, S. Zakhidov, Hardened Client Platforms for Secure Internet Browsing, in N. Pohlmann, H. Reiner, W. Schneider (Editors): Secure Electronic Business Processes, Vieweg (2008), pp. 367-379 . [7] D. Challener et. al., A Practical Guide to Trusted Computing, Prentice Hall Computing, 2007, ISBN 978-0132398428 . [8] European Payments Council (EPC), Customer to Bank Security Good Practices Guide, March 2009 (public) [9]R. Oppliger, R. Rytz, T. Holderegger, Internet Banking: ClientSide Attacks and Protection Mechanisms, IEEE Computer, vol. 42, no. 6, June 2009, pp. 27-33. NarendraKumar S, Chennai, 06.08.1989 M.E computer science and engineering, School of computing sciences and engineering, Hindustan University, Chennai, Tamil Nadu, India Arunkumar R, Chennai, 20.06.1987, M.E computer science and engineering, School of computing sciences and engineering, Hindustan University, Chennai, Tamil Nadu, India.

Vishnu chaithanya L, Chennai, 01.04.1988, M.E computer science and engineering, School of computing sciences and engineering, Hindustan University, Chennai, Tamil Nadu, India.

Chrystal Amutha D , Assistant Professor Department Of Computer Science Engineering Hindustan University,Chennai, India chrystalamutha@gmail.com

October Issue

Page 179 of 179

ISSN 2229 5208