Galexia

Submission - Joint submission to the 2007 Review of the Electronic Funds Transfer (EFT) Code of Conduct to ASIC (May 2007)

Q30 – Apart from this possible clarification, should account holders be exposed to any additional liability under cl 5 for unauthorised transaction losses because of a deception-based phishing attack? Do the benefits and costs of extending account holder liability justify such an extension? What implementation issues would have to be addressed?


[ Galexia Dots ]

The current liability regime for unauthorised transactions should not be modified so as to expand the situations in which account holders will be liable for financial losses flowing from phishing attacks. Although there are measures that can be taken by banking customers in order to combat phishing attacks, for reasons that will be discussed below these are considerably less effective than the technologies that can be utilised by financial institutions to deal with phishing. Hence, it is financial institutions who should bear the primary responsibility for implementing solutions to combat forms of online fraud including deception-based phishing attacks.

Potential Responses to Phishing Attacks and other forms of Online Fraud

There are a host of potential solutions that are available to financial institutions to combat phishing and other attacks their customers may be subjected to online. These include:

  • 1. Two Factor Authentication Solutions; and
  • 2. Website Authentication Solutions which can be installed at either the server (financial institution) or client end.

Each of these types of solutions is discussed below.

Two Factor Authentication Solutions

Two-Factor authentication refers to the use of a dual-layered approach in order to verify the identity of an end-user to a server. For example, an end-user may be required to supplement a password they have memorised (something they know) with something they have (such as a hardware token that produces a random sequence of digits at pre-determined intervals) or something they are (such as a fingerprint or other biometric data). Examples of two-factor authentication technology include RSA’s SecurID hardware tokens[28] and Australia Post’s joint undertaking with Verisign to produce a two-factor authentication system known as VIP.[29] Both of these technologies involve the use of hardware tokens provided to customers that generate random passcodes at specified intervals of time, which can be used by the customer when logging into the Internet banking section of a financial institution’s website. An alternative system adopted by some financial institutions involves sending random passcodes via SMS to an account holder’s mobile phone when they attempt to log in and/or initiate a transaction.

Two-factor authentication generally represents the limits of what financial institutions in Australia are currently implementing in response to online fraud such as phishing attacks. However, the technology provides only marginally improved resistance against phishing attacks.[30]

There is, for example, a significant possibility that the passcode displayed to a bank’s customer by their hardware token can be intercepted through the use of a spoofed website designed to falsely appear to belong to the customer’s financial institution. The website, if a convincing spoof, could cause the customer to provide the passcode displayed on their hardware token. The fraudulent party who created the spoofed website could then immediately use the passcode to login to the customer’s account as part of a replay attack (assuming they also know the customer’s password and username details). An example of this has occurred recently when account holders with Dutch bank ABN Amro had money stolen from their accounts by fraudulent parties using this very method to circumvent the bank’s use of two-factor authentication.[31]

Hence, there is a need for financial institutions to consider deploying some form of website authentication technology to prevent the use of spoofed websites (typically used as part of a phishing attack) undermining the security of customer’s login credentials.[32] A variety of these technologies are considered below.

Website Authentication Solutions

It is important to distinguish website authentication from two-factor authentication. While two-factor authentication techniques are typically not concerned with authenticating websites to users, website authentication technologies have been specifically developed to enable Internet users to verify whether the actual identity of a website aligns with the represented identity of the website. Website authentication technologies can be installed at either the client (customer) end or server (financial institution) end.

  • Server-end website authentication solutions
    Although several of the authentication technologies outlined in this section do require some level of user involvement, they have been listed as server-end since they are predominantly dependent on the financial institution for their effectiveness.
    • Shared Secrets
      A technique that is commonly put forward as a means of achieving authentication of a web server is the sharing of a secret between the server and end-user. The user may, for example, provide the server with a personal image that can then be displayed back to them whenever they wish to access the relevant website. If the wrong image is presented, the user will know that they are interacting with a spoofed website.
    • Keypad Technology
      Keypad technology involves presenting an end-user with an mage of a keypad containing a set of symbols that enables them to communicate their password to a web server. One advantage of this technology is that it is not susceptible to keystroke logging malware that may have been covertly installed on a customer’s computer by a fraudulent third party in order to capture passwords the user enters via their keyboard. Keypad technology can also be adapted to authenticate the websites of financial institutions to customers. This makes it even more effective at dealing with phishing attacks. An example of this is provided by Tricerion’s Strong Mutual Authentication keypad technology.[33]
    • Secure Remote Password (SRP) Protocol
      The Secure Remote Password (SRP) protocol prevents a shared secret, such as a password, from being compromised during communications between a financial institution and one of its customers by removing the need for the secret to be sent over a network at all.[34]
    • Challenge/Response Mechanisms
      In the context of website authentication, challenge / response mechanisms involve a client presenting a server with a challenge in order to verify the identity of the server. Using a secret previously shared between the client and server, the server calculates a response and presents it to the client. The client is able to use the response to authenticate the server.[35]
    • Delayed Password Disclosure (DPD)
      An extension of Secure Remote Password protocol, DPD enhances the effectiveness of SRP as a website authentication technology by stipulating the association of numerous images with a customer’s internet banking password. The images are presented sequentially to a customer by the financial institution’s server as they enter each character of their password during a login attempt. This process enables the customer to detect when they are dealing with a party other than the financial institution.[36]
  • Client-end website authentication solutions
    These technologies are typically installed on the end-user (customer) machine and attempt to detect phishing attacks typically through the use of heuristic analysis techniques. Examples of such solutions include:
    • Browser Chrome Enhancements
      There is an emerging trend in attempting to achieve website authentication by adding to the visual cues presented to users in the area surrounding a typical browser window. This area is commonly referred to as the ‘browser chrome’ and a host of plug-ins can be added to the web browser chrome to assist in the process of detecting spoofed websites, one of the key elements used in a phishing attack. Examples of actual and proposed browser-chrome enhancements include Petname,[37] SpoofGuard.[38] Proposed browser-chrome enhancements include Trusted Password Windows and Dynamic Security Skins.[39]
    • Email Detection
      These technologies use either heuristic or collaborative methodologies to analyse emails received by an end-user and determine whether they are likely to be phishing emails. An example of this is provided by the Cloudmark Network Feedback System.[40]

General weaknesses of client-end website authentication solutions

Although, given the inadequacies of two-factor authentication, some form of website authentication is undoubtedly needed for Internet banking in order to more effectively neutralise the threat of phishing attacks, client-end solutions are a less attractive option compared with server-end solutions. One of the reasons for this is that client-end technologies such as those outlined above rely on probabilistic methodologies (such as collaboration and heuristic analysis) in order to detect phishing attacks. This is an inherently less robust fashion of detecting phishing attacks compared to many of the methodologies employed by server-end technologies.

For example, with regard to browser-chrome enhancements the W3C paper on Limits to Anti-Phishing[41] notes:

Adding more trust indicators or more obvious trust indicators (to a web browser user interface) misses the point that an attacker can spoof every part of a user interface, including browser chrome and copy new trust indicators. Some proposals include new UI elements such as new anti-phishing trust icons, company logos in browser chrome, or new authentication popup windows. All of these miss the point that an attacker is capable of spoofing the entire user interface.

The Financial Services Technology Consortium (FSTC) is conducting a Better Mutual Authentication Project. Their recent publication – Financial Industry Recommendations and Requirements for Better Mutual Authentication[42] suggests that although modern web browsers have a fairly sophisticated array of security features, those features (particular those that can be used to authenticate websites) are often poorly integrated into the user interface, with security indicators, alerts and dialogue boxes being difficult to understand. Many end-users have difficulty understanding what the browser is telling them, while users are often provided with the option to make security warnings go away permanently.

Moreover, current web browsers allow websites to easily modify the ‘browser chrome’ – for example, by re-arranging, altering or even concealing certain elements within the browser window. This allows fraudulent parties to mislead users about the site they are viewing.

An additional problem of using browser chrome enhancements to achieve website authentication is evident when one considers that there may be situations in which end-users need to access the same websites from different machines, depending on their location. This means that they will need to install the enhancements on each machine, requiring a degree of effort which many users may simply refuse to invest.[43] Alternatively, different users may elect to install different browser chrome enhancements, each with their own level of effectiveness. Therefore different users accessing the same website may receive differing levels of protection against phenomena such as spoofed websites.


[28] RSA Security, Protecting Against Phishing by Implementing Strong Two-Factor Authentication, 2004, <http://www.indevis.de/dokumente/anti_phishing_rsa.pdf>.

[29] Deare S, Australia Post tests online identification service, ZDNet Australia, 6 September 2006, <http://www.zdnet.com.au/news/security/soa/Australia_Post_tests_online_identification_service/0,130061744,339270865,00.htm>.

[30] There have been attempts to improve the effectiveness of two-factor authentication in dealing with online fraud. See in this regard Appendix 1 – Authentication Technologies, Attempts to Strengthen Two-factor Authentication at page 50.

[31] Out-Law.com, Phishing attack evades ABN Amro's two-factor authentication, 18 April 2007, <http://www.out-law.com//default.aspx?page=7967>.

[32] Financial Services Technology Consortium, Financial Industry Recommendations and Requirements for Better Mutual Authentication, June 12 2006, <http://fstc.org/projects/docs/Recommendations_and_Requirements_for_BMA_v1.0.pdf>, page 12.

[33] Refer to 14. Appendix 1 – Authentication Technologies, Tricerion Strong Mutual Authentication at page 50.

[34] Refer to 14. Appendix 1 – Authentication Technologies, Secure Remote Password Protocol at page 52.

[35] Refer to 14. Appendix 1 – Authentication Technologies, Challenge/Response Mechanisms at page 53.

[36] Refer to 14. Appendix 1 – Authentication Technologies, Delayed Password Disclosure at page 52.

[37] Refer to 14. Appendix 1 – Authentication Technologies, Petname at page 55.

[38] Refer to 14. Appendix 1 – Authentication Technologies, SpoofGuard at page 56.

[39] Refer to 14. Appendix 1 – Authentication Technologies, Trusted Password Windows and Dynamic Security Skins at page 58.

[40] Refer to 14. Appendix 1 – Authentication Technologies, Cloudmark Network Feedback System at page 59.

[41] Nelson J and Jeske D, Limits to Anti-Phishing, W3C Workshop on Transparency and Usability of Web Authentication, 2006, <http://www.w3.org/2005/Security/usability-ws/papers/37-google>.

[42] Financial Services Technology Consortium, Financial Industry Recommendations and Requirements for Better Mutual Authentication, 12 June 2006, <http://fstc.org/projects/docs/Recommendations_and_Requirements_for_BMA_v1.0.pdf>.

[43] Fraser N, The Usability of Picture Passwords, Tricerion, 2006, http://www.tricerion.com/downloads/Usability-of-picture-passwords.pdf, page 2.