CMSC 491B Research Paper: Online Banking Security

Abstract: Today, many of the top banks in the nation offer online services to their customers that include account balance inquiries, fund transfers, paying bills, and even loan applications. Due to the sensitive nature of these transactions, banks are a prime target for attackers. However, due to banks’ wishes to make online applications user-friendly, many of their authentication methods are considered weak. Experiments performed by a group of individuals revealed that this trade-off resulted in vital security flaws that allowed them to compromise several accounts, including one of a large multinational bank. In October 2005, the Federal Financial Institutions Examination Council (FFIEC) issued guidance for banks called “Authentication in an Internet Banking Environment.” This guidance describes enhanced confirmation methods that regulators expect banks to implement when authenticating the identity of customers using on-line products and services. The effectiveness of this guidance will be explored and based on these findings an overall assessment of the security of online banking will be concluded.

The Internet has been a vital tool in communications, data exchange, and doing business. More users are becoming more comfortable with doing transactions online. Commercial businesses are also recognizing the cost benefits of performing services on the Internet. One such commerce is the banking and financial industry. The appeal of doing business with hundreds or thousands of customers at a low cost is very alluring. However, due to the sensitive information as well as the amounts of money that banks have, they are primary targets for attackers who wish to exploit them for their own gain. The security of doing business online has been a hot topic in recent years, as many people who are unfamiliar with technology do not completely trust it. However, it is not actual customers that are the frequent target of attacks; it is the banks themselves. This is due to the banks’ aspirations for user-friendly applications which caused a trade-off in weak authentication and security. This was demonstrated by a successful experiment of individuals who wished to gain control of bank accounts through the subversion of a large multinational bank’s online application. In October 2005, the Federal Financial Institutions Examination council (FFIEC) issued a guidance called “Authentication in an Internet Banking Environment” in an effort to get banks to strengthen their authentication policies. This paper will examine the following: the reason and motivation for banks to conduct business online, the successful experiment that compromised a bank’s online application, and the FFIEC guidance and its effectiveness. A final conclusion will determine whether online banking is truly secure or not and what steps banks should take in order to strengthen their current implementations, if any.

The strongest advantage for banks to conduct business online is the significant reduction in costs. Compared to a fully staffed physical staff, or even a functional ATM, the cost of Internet banking was found to be considerably smaller by a study conducted by Booz-Allen & Hamilton:

Figure 1.1: Processing Cost Per Transaction


Source: Booz-Allen & Hamilton, JP Morgan (2003)

In a business where millions of transactions are performed world-wide, banks will no doubt be attracted to the $0.01 per transaction cost of Internet banking rather than the estimated $1.07 per transaction of a branch with full service. Another benefit of the Internet is that it allows them to easily provide information to potential customers. For those who seek information on loan rates or checking account, they can easily look them up online rather than going to a physical branch or making phone calls. Convenience is the main attraction that the banks are offering to their customers through online banking. Now people don’t have to drive out to a branch, wait in a line, or even speak with a teller to conduct their transactions. They simply need a computer with access to the Internet and they’re ready to go.

These benefits lead many banks to invest heavily in implementing online banking technology. However, with their misguided requirement for user-friendly applications, conducting business online presents a security risk. In an experiment reported by a group of individuals from the Reliable Software Group of the department of Computer Science at the University of California, Santa Barbara, they were able to successfully subvert an online application of a major multinational financial institution. Their goal was to “compromise one or more accounts using the online banking service” (Ghosh 5). The compromise includes access to private information, such as the account balance and owner’s name, and the ability to transfer funds from the attacked account to another. Examining their experiment will unveil the weaknesses of the current authentication methods banks use.

Their method was pure black-box testing, where they had no information other than the name of the web site when starting their attacks. They made sure that their actions did not directly interfere with the mission of their target, referred to as Bank X. They also made no attempt to hide their attempts in order to test Bank X’s ability to detect any attacks. When they first started, they had no hint to “what the protocols used by the applications were, what the account number format was, or even what the account lockout procedure was” (Ghosh 5). They began by opening a real, legitimate account at a branch that was accessible online. Through this, it helped them to determine what protocols and message formats were used.

It was determined that Bank X’s online banking system was based on WWW technology where the user connect to a web server using a web browser. The “TCP/IP connections between the client and the server are protected against eavesdropping by means of the SSL protocol” (Ghosh 7). The procedure to log in involved filling out text fields on an HTML form that requested: a branch number that had a maximum of 4 digits, an account number with a maximum of 6 digits, a single control digit, and a PIN that consisted of 4 digits. At this point, they encountered the first flaw. Bank X wanted their system to be user-friendly; therefore, specific information is returned to the user in case one or more of the fields are filled with incorrect information. This would later be exploited. Once filling in the correct information, another authentication procedure happens that requests the users verify themselves by filling in fields such as their social security number, business tax ID number, or mother’s maiden name. Once these are verified, the user is granted access and logged in.

The first stage of their attack involved using the opened account to “determine the characteristics of the service, such as its general structure and the lockout policy” (Ghosh 7). They found that the system locks out after entering either three wrong PINs or two wrong personal data items; also, the system maintains status information across sessions, so that one cannot simply enter the wrong data, exit the system, and come back and try again. They found that the lock outs are reset every day at midnight. The next phase involved them reverse engineering the Java applet that is used on the client side. They determined that it used three Java classes for account authentication. The classes were obfuscated to make it difficult to disassemble or decompile them. They worked around this by developing a pre-decompiler that “cleaned up the classes’ bytecode by modifying two patterns that were discovered not to be properly formatted” (Ghosh 7). Once they were pre-decompiled, the classes were finally decompiled. They found that the three classes each performed a specific function: a user interface, a crypto algorithm, and an interface to the crypto algorithm. They did not study the crypto algorithm to verify its security, since they pretty much bypassed it by having the algorithm itself. They now created their own Java application that parsed the log in page to get the values returned from the server.

Their next step was to perform experiments on the system to determine what accounts existed, whether they were Internet-accessible, what the PIN number for each account was, who owned the accounts, and finally gain complete access to the accounts on the online system. They needed valid branch numbers first, which were easily available on the bank’s public web site. This can enable attackers to select a specific branch to attack, such as those that are located in large cities. Next they needed to determine what account numbers are associated with that specific branch. The account numbers were composed of a six digit number and an additional control digit. Their methodology involved them trying all ten possible control digits for each account number tried. An average of five tested control digits was used before finding the correct one. They finally collected more than “300 correct account numbers and corresponding control digits” (Ghosh 10). Using this information, they correctly reverse engineered the algorithm used to generate the control digit. They now have the ability to determine what accounts belong to which branch and whether the accounts were accessible through the Internet.

The personal identification number (PIN) is used by online banking services to identify a user. Applications require users to choose PINs that are not easy to guess; however, in the interest of user-friendliness, banks don’t require the user to use and remember a very large number. Therefore, it is a widespread practice to use 4 or 6 digit PINs. In order to defend against an attack from guessing all the possibilities of these small size PINs, “banks usually lock out accounts after a number of unsuccessful attempts” (Ghosh 10). The success of the group, therefore, relied on the size of the PIN and the number of users. To circumvent the lock out, “they fixed the PIN and varied the account number” (Ghosh 10). This resulted in no lock outs, since a particular account will be tried again with a different Pin only after numerous other accounts have been tried. Bank X also relied on an additional IP-triggered protection that locks out specific IP addresses after a certain number of failed attempts from the same IP address. They easily bypassed this by means of IP spoofing. Bank X’ PIN number was only 4 digits long, therefore there exited only 10,000 possible PIN values. They also discovered the number of online accounts, found to be around 390,000. Their experiments revealed that “if the PIN numbers were uniformly distributed and the PIN number guess was randomly generated, then the guess would be successful in matching the correct PIN for one in every 10,000 accounts tried, or .01%” (Ghosh 11). Therefore, 39 accounts would have their Pin compromised for every Pin number guessed. As a side note, it was revealed that PIN ‘1234′ was used by 3% of the users.

Their next step was to determine the name of the account owner. They did this by exploiting the funds transfer facility of the online banking system. A legitimate account was accessed, and with that they initiate a transfer request with another account that they wished to know the name of the owner. The server returns a page that contains the name of the owner of the account to confirm the transfer. The information is recorded and the transaction is finally canceled.

The final step to achieve complete access to the accounts was to answer the questions that request the personal information of the account owner. On this page it is explicitly stated that the personal data is randomly selected. Experiments found that for personal accounts two different pieces of data are requested which were either: SSN, date of birth, father’s name, and mother’s name. For a business account, the information requested was always the company’s tax identification number, or EIN. One attempt they used to get the information was by social engineering. In a small town where one branch was located, they simply talked to people who knew the account holder and asked for the pertinent information. However, they were also able to call the governmental department in charge of distributing SSNs and get these numbers. At this stage, they found a critical vulnerability: the server does not keep track of what questions were asked. Instead, it uses the text field name in the page to determine what was requested to verify. Therefore, by changing the text field appropriately, they were able to “answer the questions that they knew the answer to, rather than the questions that they were asked” (Ghosh 13). Thus, an account could be compromised even if only some of the information that could be requested was known.

For businesses, this part of the system could be completely bypassed altogether. The application always requests the EIN of the business only. However, they changed the question to request the business’s “father” with the answer as “null.” Since business accounts never have a father, the system validated this answer and granted access. The group was able to compromise the account of a large multinational corporation, which regularly performed transfers of $100,000 or more.

The group now had control and access to bank accounts. This demonstrates the weakness in security of the bank application mainly due to weak authentication. The main barriers that they had to overcome required them verifying themselves as the legitimate account owner by filling in text fields. The information that should have been known only to the account owners (such as their PIN or account number) were easily determined. The personal information was also either easily secured or bypassed altogether. The attackers did not target the customers, but rather the bank itself. Therefore, it should rest in the banks’ hands to verify and authenticate their customers rather than customers validating the banks.

In response to many banks’ similar weak authentication methods, the Federal Financial Institutions Examination Council (FFIEC) issued a guidance called “Authentication in an Internet Banking Environment.” This guidance describes enhanced authentication methods that regulators expect banks to use when authenticating the identity of customers using the online products and services. Banks are expected to be in compliance by the upcoming year 2007.

The guidance states that many banks are victims of account fraud and identity theft due to single-factor (e.g., ID/password) authentication exploitation. They suggest that banks use multifactor authentication or layered security. Some of the authentication methods mentioned include “customer passwords, personal identification numbers (PINs), digital certificates using a public key infrastructure (PKI), physical devices such as smart cards, one-time passwords (OTPs), USB plug-ins or other types of ‘tokens,’ transaction profile scripts, and biometric identification” (FFIEC).

They define multifactor authentication as having three basic “factors”: something the user knows(e.g. password, PIN), something the user has (e.g., ATM card, smart card), and something the user is (e.g., biometric characteristic, such as a fingerprint). Authentication methods that depend on more than one factor are more difficult to compromise. Certainly, if at least two factors were implemented in Bank X’s application, the group might have found it more difficult, or hopefully impossible to successfully access customers’ accounts. According to the guidance, the FFIEC recognizes that the single authentication methods that banks use currently are inadequate:

“The agencies consider single-factor authentication, as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties. Single-factor authentication tools, including passwords and PINs, have been widely used for a variety of Internet banking and electronic commerce activities, including account inquiry, bill payment, and account aggregation. However, financial institutions should assess the adequacy of such authentication techniques in light of new or changing risks such as phishing, pharming, malware, and the evolving sophistication of compromise techniques” — FFIEC

The guidance contains an appendix that describes in detail some of the authentication techniques, processes, and methodologies available. It describes more aspects of each of the authentication factors. Shared secrets are “information elements that are known or shared by both the customer and the authenticating entity” (FFIEC). Some of the examples of shared secrets are passwords, PINs, questions that require specific customer knowledge to answer, and customer-selected images that must be identified or selected from a pool of images. The shared secret is usually selected by the customer at the time of enrollment. It also states that shared secrets that never change are “described as ’static’ and the risk of compromise increases over time” (FFIEC). This authentication factor is the most widely used by banks currently due to its easy and cheap implementation.

Tokens are “physical devices (something the person has)” (FFIEC). They describe three types of tokens: the USB token device, the smart card, and the password-generating token. USB tokens are described as small devices that are plugged into a computer’s USB port. Once it is recognized, the customer is prompted on the computer to enter their password in order to gain access to the computer system. USB tokens are “hard to duplicate and are tamper resistant; thus, they are a relatively secure vehicle for storing sensitive data and credentials” (FFIEC). The smart card works in a similar fashion; it is the size of a credit card and contains a microprocessor that enables it to store and process data. In order to use one, it must be inserted into a compatible reader attached to the customer’s computer. If the smart card is recognized as valid, the customer is prompted to enter their password to complete the authentication process. Again, like USB tokens, smart cards are hard to duplicate and are tamper resistant. The FFIEC notes the primary disadvantage of using smart cards is that they “require the installation of a hardware reader and associated software drivers on the consumer’s home computer.” The password-generating token is more unique in that it creates a one-time password to be used; the OTP cannot be used consecutively. The token generates the OTP and displays it on its screen. The customer will then use their name and password combined with the OTP generated by the token. They are authenticated if the regular password matches and the OTP generated by the token matches the password on the authentication server. The FFIEC considers the password-generating tokens to be secure because of the “randomness, unpredictability, and uniqueness of the OTPs.”

The guidance explores the final factor, something the user is, through biometrics. Biometric technologies identify or authenticate the identity of a living person on the basis of a physiological or physical characteristic. Various biometric techniques and identifiers they state that are being developed and tested include: fingerprint recognition, face recognition, voice recognition, keystroke recognition, handwriting recognition, finger and hand geometry, retinal scan, and iris scan; fingerprint recognition and face recognition are described in more detail in the guidance.

Many of the methods of multifactor authentication described by the FFIEC certainly present a way to make online banking more secure. However, many banks do not implement these methods. This is mainly due to the costs of putting them into practice. Not many are willing to pay for the creation and support of the hardware needed for the second and third factors of authentication such as the smart card readers and fingerprint recognition interfaces. Also, their goal for a user-friendly experience works against this since they want the authentication process to be as transparent as possible. In fact, these methods might alienate some of the customers who are unwilling to use the smart card readers or submit their biometrics.

Not many banks are in compliance with the FFIEC guidance. Due in combination to the reluctance to invest money in the authentication methods and the fact that the FFIEC didn’t mandate the compliance with the guidelines, banks did not take it seriously early on. However, the FFIEC has stated that they will, in fact, conduct audits next year to make sure they are in compliance; many banks are scrambling to meet the December 31 deadline. Hopefully with these measures, online banking can be more secure from attackers. Then again, with banks only concerned with the bottom line and making a profit, it will be difficult for them realize the importance of online security and authentication. Despite the weak authentication, online banking is continued to be used by thousands of customers in the country. Convenience is obviously more important than the risk of the bank being undermined in the minds of the general public.

Works Cited

1. Authentication in an Internet Banking Environment." FFIEC. Federal Financial Institutions Examination Council. 16 Aug 2006 <http://www.ffiec.gov/pdf/authentication_guidance.pdf>.

2. Caldwell, Wilma R.. Computer Security Sourcebook. 1st. Detroit: Omnigraphics, Inc, 2003.

3. Cohen, Frederick B.. Protection and Security on the Information Superhighway. New York: John Wiley & Sons, Inc., 1995.

4. Ghosh, Anup K.. E-Commerce Security and Privacy. Boston: Kluwer Academic Publishers, 2001.

5. Perumal, Vignesen . "Internet Banking: Boon or Bane?." Array Development. 16 Aug 2006 <http://www.arraydev.com/commerce/JIBC/2004-12/Perumal.HTM>.

6. Stallings, William. Network Security Essentials: Applications and Standards. 2nd. New Jersey: Pearson Education, Inc, 2003.

  • Meta