«Phish and HIPs: Human Interactive Proofs to Detect Phishing Attacks Rachna Dhamija and J.D. Tygar University of California, Berkeley Berkeley, CA ...»
In Human Interactive Proofs: Second International Workshop (HIP 2005),
eds. H. Baird and D. Lopresti, Springer, May 2005, pp. 127-141
Phish and HIPs: Human Interactive Proofs to
Detect Phishing Attacks
Rachna Dhamija and J.D. Tygar
University of California, Berkeley
Berkeley, CA 94720
Abstract. In this paper, we propose a new class of Human Interactive
Proofs (HIPs) that allow a human to distinguish one computer from
another. Unlike traditional HIPs, where the computer issues a challenge to the user over a network, in this case, the user issues a challenge to the computer. This type of HIP can be used to detect phishing attacks, in which websites are spoofed in order to trick users into revealing private information.
We deﬁne ﬁve properties of an ideal HIP to detect phishing attacks.
Using these properties, we evaluate existing and proposed anti-phishing schemes to discover their beneﬁts and weaknesses.
We review a new anti-phishing proposal, Dynamic Security Skins (DSS), and show that it meets the HIP criteria. Our goal is to allow a remote server to prove its identity in a way that is easy for a human user to verify and hard for an attacker to spoof. In our scheme, the web server presents its proof in the form of an image that is unique for each user and each transaction. To authenticate the server, the user can visually verify that the image presented by the server matches a reference image presented by the browser.
1 Introduction Human Interactive Proofs (HIPs) allow a computer to distinguish a speciﬁc class of humans over a network. HIPs can be designed to distinguish a human from a computer, one class of humans from another or one particular human from another human. To do this, the computer presents a challenge that must be easy for that class of humans to pass, yet hard for non-members to pass. Additionally, the results must be veriﬁable by a computer, and the protocol must be publicly available.  In this paper, we propose a new class of HIPs that allow a human to distinguish one computer, or computer generated message, from another. Unlike The authors gratefully acknowledge partial support for this work from the National Science Foundation and the Unites States Postal Service. The views expressed in this work are solely those of the authors and do not necessarily reﬂect the views of the funding sponsors.
H.S. Baird and D.P. Lopresti (Eds.): HIP 2005, LNCS 3517, pp. 127–141, 2005.
c Springer-Verlag Berlin Heidelberg 2005 128 R. Dhamija and J.D. Tygar traditional HIPs, where the computer issues a challenge to the user over a network, in this case, the user issues a challenge to the computer. The challenge
1. be easy for a particular class of computers to pass,
2. be hard for other computers to pass, even after observing a number of successful authentications,
3. produce results that are easy for a human to verify,
4. use a protocol that is publicly available, and
5. not require the user to have specialized tools.
This class of HIPs can be used by a human to distinguish a known and legitimate website from an unknown one. Such a HIP would be useful in helping humans to detect phishing attacks. In a phishing attack, the attacker spoofs a website (e.g., a ﬁnancial services website). The attacker draws a victim to a rogue website, sometimes by embedding a link in email and encouraging the user to click on the link. The rogue website usually looks exactly like a known website, sharing logos and images, but the rogue website serves only to capture the users personal information. Many phishing attacks seek to gain credit card information, account numbers, usernames and passwords that enable the attacker to perpetrate fraud and identity theft.
About two million users gave information to spoofed websites resulting in direct losses of $1.2 billion for U.S. Banks and card issuers in 2003,  Some phishing attacks have been able to convince up to 5 percent of their recipients to respond and provide sensitive information.  Phishing attacks are successful because current web authentication mechanisms do not meet our third requirement; it is not easy for humans to verify that a successful authentication has taken place.
In Section 2, we present an analysis of authentication and anti-phishing schemes using the HIP criteria. In Section 3, we review a system, Dynamic Security Skins (DSS), that meets the HIP criteria and that allows a remote server to prove its identity by displaying an image to the user.  We present our conclusions and future work in Section 4.
2 Analysis of Authentication and Anti-phishing Schemes
2.1 Overview In this section, we analyze authentication and anti-phishing schemes using the criteria for an ideal HIP. In this class of HIP, the user issues a challenge to the
computer. The challenge must:
1. Be easy for a particular class of computers to pass. A scheme can meet this criteria if a speciﬁed server can reliably authenticate itself to the user without extraordinary resources.
Phish and HIPs: Human Interactive Proofs to Detect Phishing Attacks 129
2. Be hard for other computers to pass. Schemes meet this criteria if it is diﬃcult for illigitimate computers to masquerade as the legitimate server, even after observing a number of successful authentications. Furthermore, it should be hard for illegitimate servers to spoof the indicators of a successful authentication.
3. Produce results that are easy for a human to verify. A user should be able to verify that a successful authentication has taken place, without any undue burden on the user in terms of eﬀort, memory or time. Furthermore, in order to meet this criteria, it must by easy for a user to distinguish the legitimate server from a spoofed server.
4. Use a protocol that is publicly available. We note whether the protocol, technical details, source code or policies of the scheme are publicly available.
5. Not require the user to have specialized tools. We note whether the scheme requires users to have any specialized devices or to store or manage any secrets (e.g., cryptographic keys) in order to successfully verify a legitimate server.
In general, attempts to solve the phishing problem can be divided into three categories: third party certiﬁcation, direct authentication, and phishing speciﬁc tools. In order to discover the beneﬁts and weaknesses of each solution, we analyze them using the HIP criteria discussed above. We discuss our analysis in the next sections, and our results are summarized in Table 1.
2.2 Third Party CertiﬁcationHierarchical Trust Models
SSL/TLS. Public Key Infrastructure (PKI) has long been proposed as a method for users and servers to authenticate each other. In PKI, chains of Certiﬁcate Authorities (CAs) vouch for identity by binding a public key to an entity in a digital certiﬁcate. The Secure Sockets Layer (SSL) protocol and Transport Layer Security (TLS), its successor, both rely on PKI. SSL/TLS allows a server and client to authenticate each other and to negotiate an encryption algorithm in order to communicate privately.
In the typical use of SSL today, only the server is authenticated, by obtaining an SSL server certiﬁcate that is signed by a trusted CA. SSL also supports mutual authentication, where both the client and the server are authenticated, however this mode of operation requires the user to obtain a personal certiﬁcate. Though it is an active area of research, there is currently no practical scheme for widely deploying signed personal certiﬁcates. A further challenge is how to handle the revocation of credentials. SSL is designed to prevent eavesdropping, tampering, and message forgery in client/server communications. Instead of attacking the protocol, most phishing attacks use very simple spooﬁng techniques to trick users into believing that their connection is “secure”. Some phishing attacks exploit the fact that users can not reliably parse domain names (e.g. they can not 130 R. Dhamija and J.D. Tygar distinguish www.paypal.com from www.paypai.com or www.paypal-memberssecurity.com). Many users can not distinguish a legitimate indicator of a secured webpage (e.g. an SSL closed lock icon in the status bar of the browser) from an image of that indicator within the content of a webpage. In many browsers, there is no indicator for “unsecured” sites. This reduces the chance that users will notice spoofed trust indicators when they are inserted into an untrusted page. Other attacks simultaneously display legitimate and illegitimate webpages (e.g., in frames, multiple windows or borderless pop-up windows) in order to trick users into believing that both pages originate from the same website.
It also diﬃcult for users to understand and verify SSL server certiﬁcates.
Some phishers have gone through the eﬀort of registering a real SSL certiﬁcate for their rogue phishing sites that have a similar name to a legitimate site.  In order to detect this attack, users must be able to inspect the certiﬁcate and to distinguish the domain name of the real website from the rogue site. There are other examples where the CA certiﬁcate issuing process has been subverted (e.g., Verisign issued two Class 3 code-signing certiﬁcates to an individual who fraudulently claimed to be a Microsoft employee . A user would not be able to detect this attack by inspecting the certiﬁcate).
The SSL protocol is publicly available, and the only tool required by the user to authenticate a server is a browser that supports SSL. (To authenticate himself to the server, the user must acquire a personal certiﬁcate).
Trustbar. The Trustbar proposal is a third party certiﬁcation approach that requires website logos to be certiﬁed. The authors suggest creating a Trusted Credentials Area (TCA) as a ﬁxed part of the browser window.  This area can be used to present credentials from the website, such as logos, icons and seals of the brand that have been certiﬁed by trusted certiﬁcate authorities or by peers using a PGP web of trust.
The proposal does not specify who will certify logos or how disputes will be resolved in the case of similar logos. If the credentials are signed by trusted CAs, many of the problems of the SSL certiﬁcate validation process also apply to this proposal. A strength of this solution is that it does not rely on complex security indicators. However, we expect that all of the spooﬁng attacks that are common with SSL today will also be applied to the Trustes Credential Area.
Because the logos do not change, they can be easily copied and the TCA can be spoofed. An attacker can present an image of the TCA, with the correct logos, in an untrusted page to make it appear legitimate. The success of this attack will depend on the design of the TCA. If there is no visible indicator for unsecured windows, a spoofed TCA may not be detected by users. We expect that phishers will attempt to register logos that can be confused with legitimate logos. Therefore, the strength of this proposal will depend on the strength of the credentials registration process.
The only tool that is required by a user in this scheme is a browser that supports the Trusted Credentials Area.
Phish and HIPs: Human Interactive Proofs to Detect Phishing Attacks 131 Table 1. Analysis of authentication and anti-phishing schemes using HIP criteria
Distributed Trust Models and Third Party Seals PGP. Another third party approach is the distributed trust model, such as that used by Pretty Good Privacy (PGP).  PGP relies on third parties to sign public keys in order to attest that a public key belongs to a particular identity. Unlike centralized PKI schemes, the “web of trust” model relies on individual users to make trust judgments. This allows for more ﬂexibility in how authentication decisions are made, but it requires a great deal of eﬀort on the part of the user to carefully manage keys and to understand the delegation of trust.
It is diﬃcult to break the encryption algorithms, however one simple attack is to create a PGP key using a spoofed identity. Before attesting to a key, users are required to verify the identity of the keyholder (e.g. in a face to face meeting).
If users do not take this step before signing a key, an attacker may be able to forge a public key in someone else’s name.
Open versions of the PGP protocol are available. In order to authenticate and to verify other parties, the user must have a PGP client application (or a plug-in that implements PGP functionality, which is available for many popular e-mail applications). The user must also store and manage his own private/public key pair and the public keys of others.
This scheme is easy to use, but it is hard to distinguish legitimate sites from spoofs.
This scheme is diﬃcult to use.
This scheme requires users to carry a device and does not help users to distinguish legitimate sites from spoofs.
This scheme requires per-site customization by the user.
This scheme employs blinking border windows that may be distracting to users.
See Section 3.
132 R. Dhamija and J.D. Tygar Third Party Seals. Third party seal programs allow one party to certify another party and oﬀer a “seal of approval” that represents this certiﬁcation. For example, Verisign allows parties that have purchased a Verisign SSL certiﬁcate to post a “Secured Seal” on their websites.  Visitors can click on the seal to view a VeriSign-generated pop-up window that contains information about the website’s SSL certiﬁcate and identity. Phishers spoof this seal by copying the image into their own rogue websites. Some phishers also simulate the pop-window by hosting it on their own server, and many users can not detect that window does not originate from Verisign. While many users can recognize the seal, only sophisticated users can distinguish a legitimate seal from an illegitimate one.
These weakness also apply to other third party seal programs like TRUSTe.  The criteria for obtaining the seals is publicly available, and no specialized tools are required by the user.
2.3 Direct Authentication Direct authentication approaches include user authentication, server authentication and mutual authentication schemes.