GB2449240A

GB2449240A - Conducting secure online transactions using CAPTCHA

Info

Publication number: GB2449240A
Application number: GB0709184A
Authority: GB
Inventors: Ari Hyppoenen
Original assignee: F Secure Oyj
Current assignee: WithSecure Oyj
Priority date: 2007-05-14
Filing date: 2007-05-14
Publication date: 2008-11-19
Also published as: GB0709184D0

Abstract

Invention relates to a method of authenticating a user acceptance in respect of a transaction instruction provided to an online service on behalf of the user. The online service compiles a transaction list as an image and incorporates into this a distorted passcode (the letters "esdg" in the example shown in figure 3B). This image is returned to the user and displayed. The user is requested to inspect the transaction list and enter the displayed passcode if the transaction list appears normal. The entered passcode is returned to the online service and the transaction(s) processed only if the returned passcode matches the displayed, distorted passcode. This type of verification process is known as a reverse Turing test or Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA). The invention effectively prevents banking trojans from removing fraudulently introduced transactions from the transaction list in such a way that the change is not readily apparent to the user. Alternatively the image may contain a request for a passcode rather than the passcode itself, and the passcode may be graphical.

Description

SECURE INTERNET SERVICE ACCESS

Field of the Invention

The present invention relates to secure internet service access and is applicable in particular, though not necessarily, to a method and apparatus for providing secure internet banking access.

Background to the Invention

Use of the internet to access customer bank accounts is now commonplace. in an attempt to provide adequate levels of security, appropriate authentication and authorisation mechanisms are implemented. A simple approach is to provide customers with a usemame and password. These are requested when a customer attempts to access his or her account via the bank's web site. Such a simple approach is however extremely vulnerable to an attacker electronically eavesdropping on communications between the customer's terminal and the bank website to recover the usemame and password. Eavesdropping can be achieved in a number of ways, with currently the most common being to infect the customer's computer with a so-called "eavesdropping trojan" which detects the required authentication information and automatically transmits them to an attacker. A variation of this type of attack is to detect when the customer is attempting to access his or her bank, and to re-direct the customer's web browser to a fraudulent website which looks very similar to the bank's site. The fraudulent site accepts the username and password sent by the customer, and then returns, for example, a web page stating that the banking service is currently unavailable.

As well as eavesdropping trojans, similar attacks may be implemented using so-called "warkitting" which exploits vulnerabilities in a home user's ADSL, wireless home router, or cable modem box to cause it to reroute traffic intended for a bank's site to an attacker's site which is able to collect usernames and passwords. Attacks of this type are also known as "router attacks" or "drive-by pharming".

MW.. r)qyJ,tj Security can be improved by causing the bank's web site to request only components of the password (or components of a second password provided to the customer), for example the first and fifth letters, and changing the request at each attempted login. Of course, for relatively short passwords, it does not take long for an eavesdropping attacker to recover (or guess) the whole password.

A better approach is for a bank to provide its customers with a set of "consumable" passcodes, in addition to a username (and optional password). These codes must be used in order, and once used a passcode cannot be used again. An attacker eavesdropping on a customer's login attempt will not be able to reuse the recovered passcode for a subsequent access. Of course, a redirection attack as described above may still be used by an attacker to obtain an unused passcode.

In order to break the security provided by consumable passcodes, ever more sophisticated attackers have used so-called "man-in-the-middle trojans". The attacker installs a program on the customer's computer which intercepts traffic travelling between the customer's computer and the bank site and is capable of modifying this traffic. The trojan introduces additional transactions once the customer is logged on to the bank's site, or simply modifies the valid transaction data to perhaps change the recipient information and the amount that the customer enters. A variation of the man-in-the-middle trojan attack is to redirect bank access requests to a man-in-the-middle server which introduces the fraudulent transactions into the message flows.

It is important to note that the man-in-the-middle trojan attack can defeat the purpose of security protocols such as Transport Layer Security (TLS) and Secure Sockets Layer (SSL) designed to prevent eavesdropping and message forgery or tampering. These protocols normally ensure that the service the customer is using is indeed the real one and not a fraudulent site that simply looks like the original. Man-in-the-middle trojans can hook into web browser functions so that the trojan in effect operates "inside the browser", and sees the web page content just after it has been authenticated and unencrypted but before it is rendered on screen. In other words, the content that the bank web site sends encrypted is at this stage already unencrypted. The browser is unaware that the traffic is being monitored and/or content modified by the trojan so the M&C P54391 GB address bar displays the real address of the bank's online service, and the lock icon in the browser confirms to the customer that the identity of the web site matches the bank's online identity. If the customer double-clicks the lock icon to verify the web site identity, the page info dialog box will tell the customer that the identity has been verified by a reputable certificate authority. In short, the customer has no way of finding out that his session is being eavesdropped and/or page content has been modified before it was rendered on screen.

Typically, a customer is asked to confirm requested transactions before they are processed, so that any unauthorized transactions can be noticed. However, the fraudulent transactions may be relatively small, such that they go unnoticed by the customer. Furthermore, to avoid detection, the trojan may also modify the acceptance page by changing the part of the page that shows the fraudulent transaction so that it appears legitimate, or by simply deleting or "whiting out" the part of the page that displays the fraudulent transaction.

The trojan may alternatively accept a transaction on a customer's behalf, prior to displaying the acceptance page to the customer. Any customer acceptance or refusal is then irrelevant. To counter this, some banks require the customer to enter another password or "confirmation code" in order to confirm the requested transactions before they are processed. The confirmation codes may come from the consumable passcode list or yet another list that is indexed so that the customer may for example be asked to provide "confIrmation code F" in order to accept the transactions. Further, the confirmation code request may be implemented in the form of a graphical image that the customer knows how to react to, e.g., by clicking on certain parts of the image or by entering text shown in the parts of the image that are known to the customer only.

The advantage of the man-in-the-middle trojan to an attacker is that it can insert fraudulent transactions successfully and go unnoticed even with said confirmation code systems and yet more advanced multi-factor authentication methods. Some banks have chosen to improve the security of their online banking services through the use token-based "two-factor" authentication methods such as RSA SecurlD tokens, USB devices, or smart cards. These methods make passwords obtained through monitoring less M&( ?4i9JtjK valuable to the attacker, but they will not help against man-in-the-middle trojans that modifi the transactions the customer enters (or inject totally new transactions without the customer knowing). The customer who is unaware of the unauthorized or modified transactions will of course follow the normal course of action and enter the required one-time password or authorise the transactions using the token or smart card.

Further, a man-in-the-middle trojan attack can be completely automated, unlike the eavesdropping and redirection approaches which typically require the attacker to complete the additional step of separately logging in to a bank's site using the recovered usernames and passwords/passcodes.

It is noted that anti-virus and anti-spyware applications running on customer computers will, to a large extent, prevent attacks of the typed described above. However, in the real world not all computers are protected by anti-virus applications, whilst many that are use out of date software and/or virus definition files. Further, banks who operate online services currently have little means to ensure that a customer's computer is adequately protected, which means that they will have to blindly trust that the transaction instructions really come from the customer and not a man-in-the-middle trojan. This may expose the banks to liability for customer losses.

Summary of the Invention

It is an object of the present invention to improve access security for online services such as internet-based bank sites and more particularly to address the problem of attacks based upon man-in-the-middle trojans. This is achieved by making it very hard for a computer program to inhibit the display of transaction instructions when such instructions are presented to the user for confirmation. Examples of transaction instructions would include different types of information, such as a list of bank transfers to process, products to deliver, or recipient address details.

According to a first aspect of the present invention there is provided a method of authenticating a user acceptance in respect of a transaction instruction provided to an online service on behalf of the user, the method comprising: M&C P54391 GB at said online service, creating a file containing said transaction instruction and a passcode or passcode request combined with said transaction instruction such that both said instruction and said passcode or passcode request are intelligible to a human when the file is presented, whilst said passcode or passcode request is substantially unintelligible to a computer; sending said file to a terminal of said user and presenting the file information on an output interface of the terminal; accepting via a user interface, a passcode, and transmitting that passcode to said online service; and at said online service, accepting the transaction instruction only if the received passcode matches the passcode contained in said file or requested by said file.

It is noted that the phrase "substantially unintelligible to a computer" is used here to indicate that the passcode or passcode request is unintelligible to a computer in real-time or near real-time. This does not preclude the possibility that the passcode or passcode request is intelligible to a computer as a result of some considerable processing.

Preferred embodiments of the invention are based upon the visual presentation of information. As such, said file is an image file and intelligibility and unintelligibility correspond to readability and unreadability of displayed information. Said output interface of the user terminal is a display on which the received image file is presented to the user. Said user interface accepts a passcode from the user as a text passcode.

Embodiments of the present invention prevent an attacker from modifying an instruction confirmation request page to hide fraudulent transactions as the unintelligibility of the file makes it very hard for a computer program to recognize the part of the file that contains the fraudulent instructions and thus makes it unfeasible for the computer program to remove said fraudulent instructions from the file. This also makes it hard to hide fraudulent transactions within that page in such a way that the alteration is not visible to a user.

M&t. r)4391t,H Even if an attacker could successfully "white out" a fraudulent transaction, the displayed image will contain an obvious gap in the passcode. As an attacker, using an automated attack weapon, is unable to read the passcode or passcode request, it is unable to reconstruct the image to remove the gap in the passcode or passcode request without further distorting the passcode or passcode request.

In a preferred embodiment, said image file is a bitmap file (e.g. ".bmp"). Alternatively, the image file could be in another bitmap format such as Portable Network Graphics ("png"), Graphics Interchange Format ("gil") or Joint Photographic Experts Group ("jpg" or "jpeg"), a vector graphics format such as Scalable Vector Graphics ("svg"), an animated format such as Adobe/Macromedja Flash file format ("swi") or dynamic HTML (a combination of HTML, Style Sheets and JavaScript, collectively known as "DHTML"), or a multimedia fonnat such as Windows Media Video ("wmv"), Advanced Systems Format ("asf'), Audio Video Interleave ("avi"), Third Generation Partnership Project multimedia container format ("3gp"), Moving Picture Experts Group multimedia container format ("mp2" or "mp4"), DivX ("divx"), QuickTime ("mov" or "qt"), or RealMedia ("rm").

In a preferred embodiment, said image file is sent to the user terminal within a web page. The web page also contains a prompt to the user to enter the passcode into a data entry field of the page and to accept the entered passcode, whereupon the passcode is sent to the online service.

The passcode may comprise a set of alphanumeric characters, e.g. forming a password.

Alternatively, the passcode may comprise a set of graphical elements.

A passcode may be included within said image file by applying an appropriate distortion algorithm to certain passcode text and interlacing the distorted passcode with the transaction instruction.

In an embodiment of the invention, a passcode request can be embedded in the image, asking the user to respond by entering the passcode that corresponds to the request. In this scenario, the passcode might be retrieved from the user's printed reference list of M&L r)'vjU,ll consumable one-time or reusable passcodes, a security token, a list of memorized passcodes, facts known substantially only by the user, deduced by the user based on the information presented in the request and user's everyday experience, or some other such means. Once the passcode has been entered by the user, it can also be compressed and/or encoded via algorithms such as MD5, RIPEMD, SHA-1, SHA-256, SHA-5 12, TIGER, VEST and WHIRLPOOL.

Said image file may be an audio file, video file, multimedia file, tactile presentation or the like, which can be presented to a user via an appropriate medium. Similarly, the passcode response provided by a user may be an audio, video, multimedia, tactile, etc passcode.

The passcode and/or passcode request may be a graphical passcode or request.

According to a second aspect of the present invention there is provided a computer for authenticating a user acceptance in respect of a transaction instruction provided to a web domain on behalf of the user, the computer comprising: a first processor for creating a file containing said transaction instruction and a passcode or passcode request combined with said instruction such that both said transaction instruction and said passcode or passcode request are intelligible to a human when the file is presented, whilst said passcode or passcode request is substantially unintelligible to a computer; a transmitter for sending said file to a tenninal of said user for presentation to the user; a receiver for receiving from the user terminal a passcode; a second processor for accepting the transaction instruction only if the received passcode matches the passcode contained in said file or requested by said file.

Brief Description of the Drawings

Figure 1 illustrates schematically a web-based banking service accessed by a plurality of user terminals; M&( I'439 I Figure 2 illustrates the information flows between a user terminal, a man-in-the-middle trojan infecting the user terminal, and a web server of a bank; Figure 3A illustrates a transaction list generated by a web server prior to modification; Figure 3B illustrates the transaction list of Figure 3A following incorporation of a distorted passcode; Figure 3C illustrates the combined image of Figure 3B following modification by a trojan; Figure 4 illustrates an alternative, distorted style for the transaction list; Figure 5 illustrates a further alternative embodiment of the present invention; and Figure 6 illustrates a further alternative embodiment of the present invention.

Detailed Description of Certain Embodiments

The mechanisms described below address the problem of a man-in-the-middle trojan attack where a bank customer's computer is infected with a trojan which is able to intercept and modify information exchanged between the customer's computer and the bank's online service (facilitated by one or more servers), or where a customer's traffic is re-routed through a malicious third party site which is similarly able to observe and modiI' traffic, Figure 1 illustrates schematically the former scenario, where the man-in-the-middle trojan 1 infects a customer's computer 2 and intercepts traffic sent to and from a web browser instance 3 present at the terminal. The terminal 2 is a standard PC having a keyboard 4 for the input of user data and a display 5. Of course, the user could access the internet using a mobile telephone or the like, which could be similarly infected with a man-in-the-middle trojan. The customer's computer communicates with a bank server 6 via the internet 7. The bank server resides within a secure "domain" 7 of the bank which comprises other servers, networks and client terminals.

With reference to the information flow illustrated in Figure 2, a user accesses the homepage of his bank by entering the bank's URL into the address space of his web browser and pressing the carriage return. This causes an HTTP GET request to be sent to the bank's web server which in response returns its homepage to the customer's web browser for display. The user selects a log-in link on the homepage and a further GET request is sent to the bank's server. The server returns a bank login page. This requests 4&L Y)'fY I lTIi that the user enter a username and reusable passphrase. Upon pressing the carriage return, this data is transmitted to the bank's server. The server confirms the username and password, and returns a further web page to the web browser. This requests that the user enter a consumable passcode from a list of passcodes previously provided to the customer, e.g. on a printed sheet sent through the post or collected from a bank office.

The user enters the next unused passcode from the list into the appropriate field, and presses the carriage return again. The passcode is transmitted to the bank's server, whereupon the server validates the passcode. Assuming that the passcode is validated, the web server sends a further web page to the web browser confirming this and prompting the customer to access the available services. Up to this point the process is conventional, except that the process has been observed by the trojan 1.

At this point, the trojan has detected that the customer has accessed a bank web site, e.g. by monitoring the destination URLs of outgoing messages or the text displayed in the title bar of windows or dialog boxes on screen. It has also determined that the customer has successfully logged-on to the bank's server. If the customer decides to carry out online transactions such as inter-account transfers or bill payments, the usual exchanges take place between the customer's computer and the web server. Typically a customer sets up a number of transactions. At some point during the process, typically at the end of the user's banking session, the server converts the transaction list into a bitmap image as illustrated in Figure 3A. Payments to some recipients may be highlighted. The bank's online service could use such highlighting to draw the customer's attention to unusual transactions, for example payments to recipients that have previously not received money from this customer, international payments, or payments that are unusually large for this customer, excluding payments to recipients that are on the bank's "white list" of well-known recipients, e.g. utility companies, authorities, large companies, banks, credit card companies and the like. The highlighting could be replaced or augmented by sorting the list of transactions according to how unusual they appear, or the list could only include such unusual transactions and not the transactions that the online service would consider likely to be benign.

The web server then generates a passcode which may be randomly generated, although this is not essential. In this example, the passcode is "esdg". The server then applies an v1OA rJ'+r,urj algorithm to the passcode to distort the passcode, generating a further bitmap file. The two bitmap files are then interlaced to generate single image file as illustrated in Figure 3B. It is possible to make the passcode a more integral part of the list by, for example, making the list semi-transparent and placing the passcode "behind" the list so that telling the two apart would be even more difficult for a computer program.

The web server then includes the combined bitmap image into a further, confirmation web page and delivers this to the customer's web browser. The delivered web page includes a prompt to the user to enter into a field of the page, the displayed passcode in text format.

The man-in-the-middle trojan is of course able to intercept the delivered web page. If the trojan is programmed with sufficient optical character recognition and graphical analysis capabilities, it may perform a structural analysis of the transaction list image to identil' the part of the image where the fraudulent transaction (introduced by the trojan) is located. Once identified, it may either replace or hide the whole image, white Out the fraudulent transaction or modify the image file to delete the transaction. The trojan will then forward the web page including the modified or missing image file to the customer's web browser. Figure 3C illustrates the modified image as displayed in the customer's web browser.

The user is prompted by the displayed web page to enter the displayed passcode into a text entry box of the web page in order to confirm approval of the listed transactions.

To do this, the customer is "forced" to look at the displayed image. If the image is missing, replaced or altered to such an extent that the passcode is unreadable, the user will be unable to enter the correct passcode. If the image has been altered by removing or whiting out a single transaction, the user should immediately recognise that the image has been tampered with. The web page can, to this end, provide an informational message, perhaps embedded in the image, asking the user not to accept the list if the image appears to have been tampered with. At this point, the user should elect to abort the session, not accepting the transactions. In the event that the trojan does not attempt to modil' the image file, the customer will be able to read the passcode but should M&( 439JtiB ii observe the fraudulent transaction as it will still be present in the transaction list. Again, the user should abort the session.

it is noted that, even if the trojan does not introduce fraudulent transactions and is then able to observe a user entered confirmation passcode, this will be of no use to the attacker. The passcode is only good for one confirmation. Any subsequent attempt to introduce fraudulent transactions will result in the web server generating a new and different passcode.

The type of human verification process described above, and involving the presentation of data to a user and the re-entry of that data, is often referred to as a reverse Turing test or by the acronym CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart").

Figure 4 illustrates a modification to the process described above, in which the transaction list itself is distorted. This makes it even more difficult for a computer program to separate the passcode from the transaction list.

it is noted that the confirmation step can involve an entry means other than the terminal the request is displayed on. The passcode required for the confirmation could be requested and/or entered on a mobile phone or other "secondary" channel.

Alternatively, the confirmation request and passcode, or the passcode request, could be displayed on a secondary channel, and the confirmation then done on the terminal where the user runs the online banking session.

In a further modification to the above process, the bank server may contain instructions for the user, e.g. "GIVE CODE F", "Give confirmation code S491", "Enter the third and fifth letter of your password", or "Enter 3728 in your Security Token to get your passcode." This is illustrated in Figure 5. The web page may give further instructions to tell the user what to do. For example, "Please confirm the transactions by entering the four-letter passcode referred to in the above image from your list of reusable passcodes, then click the Confirm button". The user would then refer to a printed list of y1a. I Jt371..JO reusable or consumable passcodes, or access information produced by interacting with a security token such as a smartcard, to retrieve the passcode and enter it on the web page.

It is noted that the passcode (or passcode request) could be replaced with an alternative mechanism that requires a user to click on the displayed image with the mouse. A suitable image is displayed in Figure 6. In this example, the user would enter the passcode by clicking on an icon or several icons memorized previously, perhaps taking multiple rounds to choose icons from multiple images. Such a password entry mechanism is described in GB238 1603. Alternatively, the image could contain instructions to the user as to which icon(s) to select from a separate list.

It will be appreciate by the skilled person that various modifications may be made to the above described embodiments without departing from the scope of the invention. For example, the invention has been illustrated in the context of the visual presentation of information, in some cases, information may be presented via other media types. For example, where a transaction list is presented as synthesized speech (e.g. to facilitate use of a banking service by blind customers or telephone banking), the passcode may be interlaced into the audio file. Voice-based CAPTCHA techniques are known.

Alternatively, the transaction list and the passcode or passcode request could be presented in the form of a video presentation with computer-generated imagery and/or synthesized audio, or a pre-recorded presentation, optionally assembled from template sections in a fashion not unlike the ones used in automated phone systems that use a telephone user interface to respond to the user's keypad presses and voice commands.

It will also be appreciated that application of the invention is not limited to online banking, or indeed to providing secure access to financial services. The invention can be applied to any online transaction system including internet commerce.

Claims

M&C P54391GB CLAIMS: 1. A method of authenticating a user acceptance in

respect of a transaction instruction provided to an online service on behalf of the user, the method comprising: at said online service, creating a file containing said transaction instruction and a passcode or passeode request combined with said transaction instruction such that both said instruction and said passcode or passcode request are intelligible to a human when the file is presented, whilst said passcode or passcode request is substantially unintelligible to a computer; sending said file to a terminal of said user and presenting the file information on an output interface of the terminal; accepting via a user interface, a passcode, and transmitting that passcode to said online service; and at said online service, accepting the transaction instruction only if the received passcode matches the passcode contained in said file or requested by said file.
2. A method according to claim 1, wherein said file is an image file and intelligibility and unintelligibility correspond to readability and unreadability of displayed information, and said output interface of the user terminal is a display on which the received image file is presented to the user.
3. A method according to claim 1 or 2, wherein said user interface accepts a passcode from the user as a text passcode.
4. A method according to claim 2 or claim 3 when appended to claim 2, wherein said image file is sent to the user terminal within a web page.
5. A method according to claim 4, wherein said web page contains a prompt to the user to enter the passcode into a data entry field of the page and to accept the entered passcode, whereupon the passcode is sent to the online service.

M&C P54191GB
6. A method according to claim 4 or 5 and comprising including a passcode within said image file by applying an appropriate distortion algorithm to certain passeode text and interlacing the distorted passcode with the transaction instruction test.
7. A method according to claim 4 or 5 and comprising embedding a passcode request in the image file, requesting the user to respond by entering the passcode that corresponds to the request.
8. A method according to claim 2, wherein said passcode andlor passcode request are a graphical passcode or request.
9. A method according to any one of the preceding claims, wherein said online service is an online banking service.
10. A computer for authenticating a user acceptance in respect of a transaction instruction provided to a web domain on behalf of the user, the computer comprising: a first processor for creating a file containing said transaction instruction and a passcode or passcode request combined with said instruction such that both said transaction instruction and said passcode or passcode request are intelligible to a human when the file is presented, whilst said passcode or passcode request is substantially unintelligible to a computer; a transmitter for sending said file to a terminal of said user for presentation to the user; a receiver for receiving from the user terminal a passcode; a second processor for accepting the transaction instruction only if the received passcode matches the passcode contained in said file or requested by said file.