Identifying an OpenID anti-phishing scheme for cyberspace

SECURITY AND COMMUNICATION NETWORKSSecurity Comm. Networks (2014)

Published online in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/sec.1027

SPECIAL ISSUE PAPER

Identifying an OpenID anti-phishing scheme forcyberspaceHaider Abbas1,2*, Moeen Qaemi Mahmoodzadeh2, Farrukh Aslam Khan1,3 and Maruf Pasha4

1 King Saud University, Riyadh, Saudi Arabia2 National University of Sciences and Technology, Islamabad, Pakistan3 National University of Computer and Emerging Sciences, Islamabad, Pakistan4 Department of Information Technology, Bahauddin Zakariya University, Multan, Pakistan

ABSTRACT

OpenID is widely being used for user centric identity management in many Web applications. OpenID provides Web userswith the ability to manage their identities through third party identity providers while remaining independent of the subjectthat actually uses the identities to authenticate individuals. Starting from the early stages of its inception, OpenID hasreceived a large amount of acceptance and use in the current Web community because of its flexibility and ease of use.However, in addition to its benefits and flexibilities, OpenID faces its own share of vulnerabilities and threats, which havemade its future and large-scale use in cyberspace questionable. OpenID Phishing is one such attack that has received muchattention and that requires a comprehensive solution. This paper aims at identifying and discussing a solution to OpenIDPhishing by proposing a user authentication scheme that allows OpenID providers to identify a user using publicly knownentities. The research will help in next-generation cyber security innovations by reducing the authentication dependency onuser credentials, that is, login name/password. The authentication scheme is also validated through detailed descriptions ofuse cases and prototype implementation. Copyright © 2014 John Wiley & Sons, Ltd.

KEYWORDS

OpenID; phishing; password-less authentication; secure OpenID provider; cyber security innovations

*Correspondence

Haider Abbas, Centre of Excellence in Information Assurance, King Saud University, Riyadh, Saudi Arabia.E-mail: [email protected]; [email protected]

1. INTRODUCTION

The Internet and the World Wide Web have become asignificant part of our social and professional lives. NewWeb services and websites providing services such asemail, online shopping and ecommerce, social networking,and other information services appear every day, attractingmasses of new and existing users to the Internet and theWorld Wide Web. With such increased usage and interac-tion with the Internet, as well as the manner in which weconduct business and communicate with our colleagues,friends, and family, the demands for confidentiality, integ-rity, privacy, and availability have also increased. In orderto achieve the aforementioned demands, user identificationand authentication have very important roles to play, wherepasswords are one of the most commonly used means ofend user identification and authentication. A password, asa secret shared between two parties to identify one partyto the other, is often associated with a username to createa unique pair. Username and password pairs have beenand are still the primary means of identification and

Copyright © 2014 John Wiley & Sons, Ltd.

authentication over the World Wide Web, where websitesand Web services distinguish and identify users based onusername and password pairs, which they had previouslyasked the users to set at the time of their registration. Asa consequence, as the number of Web services that a userneeds to access increases, so does the username andpassword pairs that he or she has to produce and remem-ber. Thus, it becomes a difficult and intimidating task toremember the various username and password pairs forall of the services for which a user is registered. Thisdifficulty produces other problems. For example, usersare often forced to resort to weak password protectionpractices such as repeating their login credentials overmultiple websites or services, creating weak and easy toremember passwords, or writing their login details on apiece of paper for future reference, which increases thethreat of a password compromise and the eventual theftof the user’s identity and the underlying service(s).

A solution to the aforementioned problem came withthe emergence of single sign on (SSO) systems, whichprovided users with the flexibility of creating a single login

Identifying an OpenID anti-phishing scheme for cyberspace H. Abbas et al.

profile with the capability of authenticating to several depen-dent servers [1]. These systems reduced the overhead forusers to create separate login profiles for the services theywould like to use and the need to remember their respectivepasswords. In fact, now, the user would only need to createand register a single profile on the SSO system and use thisprofile to gain access to all their services. In addition, oneof the most important features of most SSO systems is thatonce a user is logged into the SSO system, the system seam-lessly authenticates the user to the dependent website orservice, without asking the user to provide their credentialseach time they access a new service or website. NumerousSSO systems have recently been developed, includingWindows Passport [2], Shibboleth [3,4], Liberty [5], SAML[6], Kerberos [7], and OpenID [8].

OpenID Phishing is an attack that targets the OpenIDuser with the goal of tricking the OpenID user into disclos-ing their secret login credentials to the attacker. This resultsin a number of issues, including identity loss, the misuse orabuse of the lost identity, and the loss of the user’sreputation and underlying services. Although most of thestrategies for implementing this attack are tactful, a largenumber of people still become victims of this attack. Thus,a comprehensive solution to the problem is required that isnot only effective but also user friendly, flexible, and easyto implement.

2. BACKGROUND

OpenID is a distributed, open source, user centric,Web-based identity management, and SSO system. Itsdevelopment began in 2005. It allows users to develop,define, and manage identity profiles that can be used toidentify and authenticate them to websites and Webservices, without requiring the user to register with eachservice or website individually. As an SSO system, oncea user successfully logs into the system (OpenID provider),the system manages its SSO capabilities without requiringthe user to re-enter their login credentials each time he orshe visits a new website.

Each individual user of the OpenID system is called anOpenID user. Each OpenID user is identified by a uniqueidentifier known as the OpenID identifier, which could bea uniform resource identifier (URI) or extensible resourceidentifier. The OpenID user uses its OpenID identifier asits digital identity to initiate the identification and authenti-cation process with a website or a Web service, which isknown as the OpenID relying party. The OpenID relyingparty is a website or a Web service that supports OpenIDauthentication and relies on an OpenID provider to authen-ticate a user of the relying party.

Out of all the parties already discussed in the OpenIDprotocol, the OpenID provider has a pivotal role in ensur-ing the appropriate functioning and security of the overallprotocol. The initial responsibility of an OpenID provideris to register an OpenID user to its end and request thatthe User provide information that they are willing to share

as user information with the OpenID Relying Parties. TheOpenID provider provides every OpenID user with aunique OpenID Identifier, which the OpenID user uses toidentify himself to the OpenID relying party and initiatethe authentication process. The second important role theOpenID provider plays is that it is responsible for theauthentication of the OpenID user who is willing to accessthe services of the OpenID Relying Party, through anauthentication mechanism defined and controlled by theOpenID provider. Third, the OpenID provider is responsibleto manage the SSO capability provided by the OpenID SSOsystem, thus ensuring that the OpenID users can access anOpenID relying party without the OpenID user providinghis or her credentials for authentication again and again.

The ease, flexibility, openness, and user centric natureof the OpenID protocol allows a user to take control ofhis or her identity and the amount of information that isshared with the accepting relying parties (user federation).This is the characteristic of OpenID that has made it one ofthe most preferred and highly implemented SSO solutionsfor the Web. Since its inception, OpenID has been widelyaccepted by the Internet community, and a large numberof websites and services have appeared that rely on severalindependent OpenID providers for their registration andauthentication requirements. Nowadays, Google, IBM,Microsoft, VeriSign, and Yahoo! are OpenID Foundationcorporate board members [9], which show the wide accep-tance of this technology and the assured future of it.

Although the OpenID protocol provides a lot of flexibil-ity and benefits for communication, the protocol contains anumber of weaknesses and vulnerabilities, includingvulnerabilities to a man-in-the-middle attack and crossserver side request forgery. Research on identifying andremoving these weaknesses started at the early stages ofthe inception of this protocol, which resulted in two furtherversions of the protocol to be revised and released. Despitethe thorough review of the protocol from its earlieststage, significant weaknesses are still present within theframework of the protocol, inherent in its architecturaldesign and the World Wide Web (the technology it resideson). Problems such as end point trust, phishing, and singlesign out are some of the key issues with OpenID that havenot been resolved.

A lot of research has been carried out by researcherswith the intention to review the security vulnerabilities inthe protocol and its SSO capabilities. The efforts ofTsyrklevich and Tsyrklevich [10], Max Charas [11], andOh et al. [12] are significant in this regard. The authorsin [10,11] focused on the weaknesses in the actual protocoland highlighted issues such as a man-in-the-middle attackbecause of the use of the Diffie–Helman key exchangeprotocol, and phishing and cross server side frame forgery.The authors also identified a set of technical controls orsolutions to handle these problems individually. Oh et al.[12] highlighted weaknesses in the SSO capability of theprotocol and exploited it through an exchange of nonceby performing a replay attack. A solution to the specifiedproblem was also proposed. Although numerous reviews

Security Comm. Networks (2014) © 2014 John Wiley & Sons, Ltd.DOI: 10.1002/sec

Identifying an OpenID anti-phishing scheme for cyberspaceH. Abbas et al.

and studies of the protocol have been performed, problemssuch as phishing, end point trust, and single sign out stillrequire a comprehensive solution. Questions like whatwould be the impact of the compromise of an OpenIDprovider server? What would be the impact of an OpenIDprovider going rogue? What are the security considerationsfor establishing trust? How can you completely protect aUser from phishing? How can you ensure OpenID userprivacy? How can trust be ensured in such an open anddistributed environment? These are questions that arecurrently being ignored by the Web community, but areassociated with the current large scale and ever increasingimplementation of OpenID; the risk of impact from thesepending issues is increasing.

This paper will discuss one such issue—OpenIDPhishing—by proposing and evaluating a robust and userfriendly solution to it. The preliminary framework of thisanti-phishing mechanism was presented in [13]. Sections 1and 2 of this paper provide an introduction to and the back-ground of OpenID, along with OpenID’s weaknesses andvulnerabilities in general. Section 3 discusses related workon protective measures for OpenID Phishing, authenticationschemes, and other vulnerabilities. Section 4 of this paperwill discuss OpenID Phishing in more detail, whilediscussing the different possibilities of phishing attacks onan OpenID user. Section 5 of the paper will discuss thedetails of the proposed solution to the OpenID Phishingproblem with reference to the different schemes of phishingattacks discussed in Section 4 and how and why theproposed scheme protects against the attack. Sections 6 and7 present the prototype implementation details and anevaluation of the protection scheme, respectively. Section 8provides a conclusion to the entire research work along withfuture research directions.

3. RELATED WORK

A significant amount of research has been carried out toaddress the problems with OpenID. Different discussionshave also appeared on this topic in the form of papers,blogs, and dissertations that have discussed the securityissues of OpenID and proposed different solutions to theproblems. OpenID Phishing is one such problem that hasbeen discussed on numerous platforms, with different solu-tions being proposed for it, after it was first identified in thewhite paper of Tsyrklevich and Tsyrklevich [10]. Thework of Max Charas [11] discusses solutions to OpenIDPhishing in the form of a user checking the URL of thebrowser client to confirm its correctness and an automatedmechanism that uses a browser plug-in to identify potentialphishing attacks. At the OpenID provider’s end, Charas[11] proposes that the OpenID provider could make its userinterface more identifiable by adding a user specific tag inthe form of a picture that the user can identify to be missingin the phishing website. One of the most recent works re-lated to the OpenID Phishing problem was by Lee et al.[14], where the authors proposed anti-phishing methods


using token and authentication emails. Feng et al. andHuang et al. [15,16] also proposed an effective model toavoid phishing based on two types of passwords. Previousstudies [17–22] present user key management and secretsharing schemes for user identification/management. K.Peng [23], Obaidat and Zarari [24], and Aikebaier et al.[25] presented trustworthy and secure algorithms forencryption and trust management. Islam and Abawajy [26]and Mao et al. [27] presented an effective anti-phishingmechanism for emails.

4. OPENID PHISHING

Phishing is a Web-based attack, in which an attackercreates a fake duplicate website and redirects non-expectingusers to it with the intention of deceiving the user intoleaking any classified or private information. In most cases,phishing attacks aim at the login pages of websites with theintention to steal the login credentials of users or attackwebsites that ask for some private or personal informationsuch as a credit card number, social security number, or bankaccount details.

Because OpenID is a Web-based technology, amongthe numerous threats that it inherits from the Web and itsown architectural design, the most significant is the threatof an OpenID Phishing attack. An OpenID Phishing attacktargets an OpenID user by forging a valid OpenID providerLogin Interface, with the purpose of tricking the OpenIDuser into entering their login credentials on the fakeinterface. Like all other Web-based technologies, the mostcommon authentication mechanism used in the OpenIDSystem is a username and password pair, which is whatan OpenID Phishing attacker is looking for [32]. Once anattacker gets access to an OpenID user’s login credentials,they will then have the keys to their castle, where they canmasquerade as the user and thus register and make use ofdifferent services on the user’s behalf. A single lapse insecurity can severally damage a user’s digital identity, theirassociated reputation, and in some cases cause financialloss and the loss of credibility. Thus, an effective solutionto the OpenID Phishing problem is needed to ensure theeffective and secure use of the technology in the future.

The next sections discuss three scenarios or cases, whichexplain various techniques through which OpenID Phishingcould occur. These three cases are in no way a declaration ofthe limitations in which OpenID Phishing could take place,but, in reality, only depict the most common approaches tophishing in OpenID, as discussed in [28].

4.1. Scenario 1

In this type of attack scenario, the OpenID relying party isrogued with the intention of stealing an unsuspectingOpenID user’s login credentials, which will enable themto masquerade as the victim in the future. The attackercreates a fake but identical website similar to that of theOpenID provider for the OpenID user, hosted on a fake


domain and having exactly the same interface as the originalOpenID provider. Instead of authenticating the credentials ofthe user, the attacker keeps the entered login credentials forfuture use. It tricks the OpenID user by presenting anotherlogin page and acting as the real OpenID provider, while actu-ally redirecting the user back to the relying party. The user isnot able to detect that the data entered were not for the originalOpenID provider but, in fact, was sent to an attacker phishingfor their credentials. There could be many other variations tothis attack, which are outside the scope of this paper. It shouldbe noted that the attacker is presented (original or faked) as therelying party but is attempting to acquire the user’s credentials.Thus, in this case, the OpenID relying party considers this as alegitimate request and puts it through to the fake OpenIDprovider’s webpage, and the identity is compromised.

Figure 1 shows this phishing scenario, where an OpenIDuser sends a login request to the OpenID relying party and pro-vides its OpenID user identifier. The OpenID relying partybeing rogue, after seeing the provided identifier as in step (2)of Figure 1, redirects the user to the phishing website createdpreviously. After getting redirected to the fakewebsite, it givesthe user credentials to the fake OpenID provider, whichresponds as a legitimate provider to the user and pretends toaccept the provided credentials. It then forwards them backto the OpenID relying party, as shown in steps (4) and (5).The rogue relying party accepts the user, whichwas forwardedby the fake OpenID provider, thus making the attackunrecognizable to the OpenID user, who is unaware that anattack has taken place. In this whole attack scenario, no actionof the OpenID relying party, or the fake OpenID provider(created with the purpose of phishing the unsuspecting user),gives the OpenID user the feeling that they are under attack.

4.2. Scenario 2

The second case or scenario for an attack is an extension ofthe scenario discussed previously, where the attacker is anOpenID relying party willing to get access to the OpenIDidentifier of an unsuspecting victim. In this case, theattacker has the ability to adapt to the requirements ofperforming a phishing attack by dynamically forging the

Figure 1. Graphical representation of most common (scenario#1) OpenID Phishing attack.

login page of the OpenID provider on the fly, after discov-ering it as a result of the discovery step in the OpenIDauthentication process. The major difference between thetwo discussed is, in the latter case, the OpenID relyingparty is more intelligent and adaptive to the requirements,which yields a far more successful phishing attack.However, the complexity of implementing such an attackis comparatively high.

Figure 2 depicts this phishing scenario, where similar toscenario 1, the OpenID user accesses a rouge OpenID relyingparty having the capability of identifying the OpenIDprovider of a user by checking its OpenID identifier, andcreating an identical but fake OpenID provider on the run,providing to the OpenID user a similar user login experience,with the purpose of tricking the user into disclosing his or heruser credentials, as shown in step (2) of the figure.

The OpenID relying party redirects the OpenID user tothe fake OpenID provider interface, which, similar toscenario 1, asks the user for their login credentials. Whenthese are provided by the user, they are accepted, and the useris redirected back to the rouge OpenID relying party to beaccepted as an authenticated user, as shown in step (4).

4.3. Scenario 3

An unusual but highly likely phishing attack capitalizes ona common vulnerability in human behavior, which is thebehavior of providing a predefined response or reactionin a known or similar situation. This relates to an importantaspect of Web usage, which causes a user to respond in asimilar way each time the user comes across the same orsimilar situation. This vulnerability in human behaviorcan be exploited by an attacker who hosts a maliciousOpenID relying party, which this time, besides redirectingan OpenID user to a fake OpenID provider, provides itsaccessing OpenID user with an interface common tonormal login interfaces asking for the user’s usernameand password combination, rather than the commonmethod of requesting the OpenID identifier.

The user, being new to the technology and the sequencefollowed to authenticate a user, and/or being influenced bythe predefined behavior of response (as explained above),provides their OpenID provider’s username and password,which it had to provide at a later stage at the OpenIDprovider’s end. This mistake results in the disclosure of

Figure 2. Graphical representation of possible attack scenario(scenario #2) for OpenID Phishing.



the OpenID user’s credential to the attacking OpenIDrelying party, who has successfully tricked the user intoexploiting the weakness in the user’s behavior. Althoughthis attack seems highly unlikely, the simplicity of theattack, supported by the deviation from the normal OpenIDauthentication process and the tendency in human behavior(to follow a common pattern and norm), increases theprobability of its success.

Figure 3 gives a graphical representation of thediscussed third type of OpenID Phishing attack, wherethe OpenID relying party tricks the OpenID user intogiving out their login credentials by providing the userwith an interface that asks for the user’s username andpassword instead of the OpenID identifier.

All of the previously defined attack cases/scenarioshave one thing in common, namely, the use of a usernameand password pair as an authentication mechanism. Therehave been a number of solutions defined for phishing.For example, Charas [11] discussed solutions such aschecking the URL of the OpenID provider website forsuspicious entries, or having an OpenID provider create auniquely identified page for the user that it could recognizewhen the user is not redirected to the correct OpenIDprovider, or using a specialized browser plug-in to detectpossible phishing attack. Further counter measures includeuser awareness and training, which is the most recommendedsolution. However, there are still cases where a person canget tricked into giving away his credentials in a phishingattack. Phishing attacks are possible primarily because thereis a shared secret (pre-known or dynamically generated)between the requester and the verifier/authenticator that isused to authenticate both the parties. These shared secretauthentication schemes are the username/password-basedauthentication scheme; biometric-based authenticationscheme, where a biometric template of the user is a sharedsecret between the user and the system; and even the dualfactor authentication scheme of a token-based value andshared secret pin. In all the aforementioned schemes, oncean attacker gets access to the shared secret (between therequester and the authenticator), they can use it to masquer-ade as the true user and benefit from his or her services. Thiscapability of an attacker to use a victim’s credentials couldbe indefinite in the case of a disclosure of the username

Figure 3. Graphical representation of possible attack scenario(scenario #3) for OpenID Phishing.


password pair or biometric template, or it could be within acertain time limit such as in the case of the dual factorauthentication of a random token value and shared secret pin.

Taking the aforementioned factor into consideration, itis quite obvious where the problem lies, which is the useof shared secrets (permanent or dynamic) such as usernameand passwords pairs to authenticate users to the system.Thus, if one could remove the root cause of the problem,which is the shared secret-based authentication, andreplace it with something as equally effective but nothaving the same vulnerabilities, the problems with phishingattacks could be solved. In essence, the best solution to aphishing attack is replacing authentication based on sharedsecrets such as passwords, by creating an authenticationmechanism that relies on publicly available information toidentify and authenticate a user, with the purpose of removingthe possibility of identity theft based on the disclosure of ashared secret. Keeping the aforementioned considerationsin perspective, this paper will propose and evaluate a pass-word-less authentication scheme for OpenID, as a solution tothe OpenID Phishing problem, which will also eliminate allthe previously discussed possibilities of phishing attacks.

5. PROPOSED AUTHENTICATIONSCHEME

The authentication scheme proposed in this paper, asdiscussed earlier, removes the dependency of verifying anindividual based on a shared secret such as a username pass-word pair, dynamically generated password, or biometrictemplate. In fact, it uses public key cryptography as a meansto achieve its goal of password-less authentication.

The proposed authentication scheme relies on a challengeand response mechanism to identify a requesting party in theauthentication process. Once an OpenID user requests au-thentication to the OpenID provider, an OpenID providergenerates a random (R) and transmits it to the OpenID userencrypted by the receivers’ public key K[U]pub, as achallenge to the requesting party. The receiver (OpenIDuser) decrypts the encrypted R using its private key andcreates and transmits a response back to the OpenID providerbased on the received value R. Upon receiving the responsefrom the OpenID user, the OpenID provider evaluates andverifies the received value using the value for its correctnessas per its expectations. If the received response complieswith the OpenID providers expectations, this results in asuccessful authentication of the OpenID user; if not, it fails.

This section explains the proposed solution in detail,specifically focusing on the handshake protocol used toauthenticate the user to an OpenID provider. However,before discussing the proposed authentication scheme, thefollowing assumptions need to be considered:

(a) The OpenID user and OpenID provider each hold apublic and private key pair.

(b) The OpenID user provides its public key (digital certif-icate) to the OpenID provider at the time of registration.


The following describes the newly proposed authentica-tion process with the purpose of solving the OpenID Phishingproblem. The discussion is divided into numbered parts forthe reader’s convenience, and each number element couldbe considered as a step in the authentication process.

(1) The user accesses the relying party and providestheir OpenID URI or extensible resource identifierin the specific text box available in the relyingparty’s interface to enter the OpenID identifier.

(2) The relying party, upon receiving the OpenID identi-fier, identifies the end point address of the OpenIDprovider by passing the identifier through the OpenIDprovider discovery phase, and the user is thenredirected to the OpenID provider.

(3) Once the user is redirected to the OpenID provider,the OpenID provider asks the redirected OpenIDuser for their username and public key, which theOpenID provider had acquired at the time ofthe registration of the user to the provider. TheOpenID provider is expected to have a securerepository of OpenID user usernames and publickey pairs for all its registered OpenID users.

(4) The user provides his or her username and the pub-lic key identified as K[U]pub.

(5) The OpenID provider validates the username andpublic key pair to identify the associated OpenIDURI. The provider does so by comparing the infor-mation it has stored against the specified identifier,provided by the user at the time of registration.This verification of the provided OpenID user pub-lic key with the already stored public key is highlyimportant to prevent the OpenID user from beingfaked by an attacker, who provides his or herown public key with the OpenID user’s username,thus claiming the identity of an OpenID user. Thecomparison will not allow such an attack to be suc-cessful. Even if the public key of the OpenID useris publicly known, the authentication scheme isprotected by the protection and secrecy of the pri-vate key. Hence, even if an attacker enters theOpenID user’s public key, he or she does not havethe corresponding private key to complete a suc-cessful authentication

(6) Once the verification is done, the OpenID providergenerates a random number R using the currenttime T XORed OpenID provider private key K[P]prv as the seed state to the cryptographically securepseudo random number generator (CSPRNG).

R ¼ CSPRNGðT⊗K P½ �prvÞ

Once R has been generated, the OpenID providerconcatenates the OpenID provider’s public key K[P]pub with the generated random value R to formK[P]pub.R. The OpenID provider then concatenatesits IP address as the source address for the messagewith K[P]pub.R to form K[P]pub.R.IPidp.The OpenID

provider generates nonce Nidp by taking time T asthe random nonce and concatenates it to the previousmessage to form K[P]pub.R.IPidp.Nidp.After gene-rating the message K[P]pub.R.IPidp.Nidp, the OpenIDprovider generates a random secret Key [K]secand encrypts the previously formed message withthe newly created random secret Key [K]sec. Afterthis step, the final message can be depicted asE{K[P]pub.R.IPidp. Nidp}Ksec.

(7) The OpenID provider then uses the public key (K[U]pub) of the OpenID user, which it has kept afterthe user’s registration to encrypt the random secretkey [K]sec in order to generate E{[K]sec}PKidu. Theprotocol then proceeds further by the OpenID pro-vider concatenating the encrypted message E{K[P]

pub.R.IPidp. Nidp}Ksec and the encrypted secret keyE{[K]sec}PKidp to form E{[K]sec}PKidu.E{K[P]pub.R.IPidp. Nidp}Ksec.

The protocol goes further to create a digital signa-ture Hsig[p] on the encrypted pair of messages E{[K]sec}PKidu.E{K[P]pub.R.IPidp. Nidp}Ksec usingits private key (K[P]prv). The generated signatureHsig[p] is concatenated to the encrypted messagepair to form the message that is finally sent to theOpenID user.

Hsig p½ �:E K½ �sec� �

PKidu:E K P½ �pub:R:IPidp:Nidp

n oKsec:

The scheme can use any public key based crypto-graphic algorithm to encrypt and digitally sign themessages: RSA [29] and ElGamal [30] are two verysuitable candidates for the required computations.the digital signature could be calculated using anysuitable hashing algorithm such as SHA256 [31] togenerate a hash [H] of the messages.

(8) Once Hsig[p].E{[K]sec}PKidu.E{K[P]pub.R.IPidp.Nidp}Ksec has been generated, the OpenID pro-vider sends the information to the OpenID user.

(9) After the OpenID user receives the encrypted andsigned message from the OpenID provider, it willfirst decrypt the encrypted secret key E{[K]sec}PKidu using its private key, to retrieve the secretkey [K]sec from the received message. Once the se-cret key [K]sec has been successfully retrieved, theOpenID user uses the retrieved secret key [K]sec todecrypt the remaining portion of the encryptedmessage E{K[P]pub.R.IPidp.Nidp}Ksec to retrievethe public key of the OpenID provider K[P]pub,the random R, and the IP address of the sourceIPidp. The OpenID user then moves on to verifythe digital signature Hsig[p] to ensure that thereceived message was not tampered with duringtransmission. If the message is found to be tamperedwith, the authentication protocol ceases to continue,or else it proceeds. After the digital signature of thereceivedmessage is confirmed, the OpenID user con-firms the freshness of the nonce Nidp to ensure thatthe packet received is fresh and is not a packet from



SeDO

a replay attack. The OpenID user then moves for-ward by comparing the received source IP addressIPidp (encrypted in the message) with the source IPaddress of the received packet. If the comparison pro-duces a positive result, the protocol proceeds to thenext stage. If not, a possible man-in-the-middleattack is identified, and the protocol does not proceedfurther. A discussion on how this comparisonprotects against a Man-in-the-Middle attack (MITM)will be provided in Section 8 of the paper.

(10) Once the verifications are complete, the OpenIDuser generates the value of R′, the value it willsend back to the OpenID provider to prove itsidentity. The value R′ is calculated at theOpenID user’s end using the OpenID provider’srandom R XORed the shared secret key [K]secas the seed for the cryptographically securepseudo random number generator CSPRNG.

R′ ¼ CSPRNG R⊗ K½ �sec� �

The OpenID user then concatenates its own IPaddress, along with the IP address of its desti-nation (OpenID provider), as the source anddestination IP addresses for the message, usingthe newly generated random R′ to form R′.IPidu.IPidp. The OpenID user then takes thecurrent time T as Nonce Nidu as a protectionto replay and relay attacks and concatenates itto the message R′.IPidp.IPidu to produce R′.IPidu.IPidp.Nidu. The addition of source anddestination IP addresses to the response to theOpenID provider has the goal of protecting theprotocol from a potential MITM attack, whilethe Nonce Nidu ensures the freshness of themessage.Once the message R′.IPidp.IPidu.Niduhas been generated, the OpenID user moves furtherby generating a random secret key, as donepreviously [K]sec. Once the random secret key isgenerated, the protocol moves forward with theOpenID user using it to encrypt the message R′.IPidu.IPidp.Nidu to form E{R′.IPidu.IPidp.Nidu}Ksec. After calculating E{R′.IPidu.IPidp.Nidu}Ksec,the OpenID user uses the public key of the provider(K[P]pub) to encrypt the random secret key [K]sec,thus forming the message E{[K]sec}PKidp.

As a next step, the OpenID user concatenates theencrypted message pair E{[K]sec}PKidp and E{R′.IPidu.IPidp.Nidu}Ksec to form E{[K]sec}PKidp. E{R’.IPidu.IPidp.Nidu}Ksec.

To protect the integrity of the OpenID user’sresponse, a digital signature is calculated by theOpenID user, using its private key (K[P]prv) onthe message E{[K]sec}PKidp. E{R′.IPidu.IPidp.Nidu}Ksec. The calculated digital signature Hsig[u]is appended to the message to form.

Hsig u½ �:E K½ �sec� �

PKidp:E R′:IPidu:IPidp:Nidu� �

Ksec

curity Comm. Networks (2014) © 2014 John Wiley & Sons, Ltd.I: 10.1002/sec

(11) The message Hsig[u]. E{[K]sec}PKidp. E{R′.IPidu.IPidp.Nidu}Ksec will be sent to the OpenID providerand will be used to validate the OpenID user.

(12) The digital signature Hsig[u] of the message Hsig[u]. E{[K]sec}PKidp.E{R’.IPidu.IPidp.Nidu}Ksec willbe verified by the OpenID provider using theOpenID user’s public key, and the authenticationprotocol disconnects the connection if the hash ver-ification fails. This could be due to intentional orunintentional/accidental tampering during transmis-sion. If the verification succeeds, the private key ofthe OpenID user K[P]prv will be used to decrypt E{[K]sec}PKidp and retrieve the random secret keythat was used to encrypt E{R’.IPidu.IPidp.Nidu}Ksec.

After decrypting the secret key [K]sec, theOpenID provider decrypts E{R’.IPidu.IPidp.Nidu}Ksec using [K]sec to retrieve R′.IPidu.IPidp.Nidu,. Nidu

is the nonce that is used to protect from a replay at-tack, and Rʺ is the response for the OpenID pro-vider’s challenge, that is, R. In addition, the IPaddresses of the source and destination are embed-ded to counter a MITM attack.Once the message isdecrypted, the nonce Nidu. will be checked for valid-ity, and the protocol will continue to generate Rʺ ifNidu is valid, as follows.

R″ ¼ CSPRNG R⊗ K½ �sec� �

Otherwise, there could be a possibility of a replay at-tack, and the authentication will be suspended. Afterthis, the generated value Rʺ will be compared withR, and the authentication succeeds if the valuesmatch. This comparison is a significant point in theauthentication of the OpenID user to the OpenIDprovider, as R in the calculation of Rʺ indicates tothe OpenID provider that the message it receivedcontaining R′ was calculated by the OpenID userthat it had shared the value R with. The OpenID pro-vider verifies the source and destination IP addressesreceived in the encrypted message using the IP ad-dresses of the received packet, which ensures thata MITM is not taking place.

(13) Once the OpenID user is authenticated successfully,they will be redirected to the OpenID relying party.

The proposed authentication protocol with thedetailed numbering of its various steps is depictedin Figure 4.

The protocol described earlier will generate de-tailed error messages with error descriptions if theauthentication or comparison of keys, nonce, andso on fails at any point (described as protocol steps).The error description can be customized or rephrasedfor the user’s understanding and technology used.

6. PROTOTYPE IMPLEMENTATION

This section will discuss the implementation details of theproposed scheme in the real world. It should be noted that

Figure 4. Proposed authentication protocol of message handshake.

Figure 5. User login prompt at OpenID provider’s websiteafter redirection.

Figure 6. OpenID desktop app interface.


there are also other possibilities for implementing thisscheme using different technologies and methodologies.

The proposed implementation scheme involves twoapplications, one running at the OpenID provider’send, which will be the OpenID provider website with thespecialized authentication page supporting the proposedscheme, and the other the desktop-based application runningat the client’s end and supporting the authentication scheme.The current implementation uses C#, ASP.net, and AJAX.The OpenID provider will acquire the following informationfrom the user at the time of registration.

(1) Name (and other personal information if required)(2) Proposed username (from user or OpenID pro-

vider’s recommendation)(3) A public key (an option from the OpenID provider

to provide his or her public key that can be securelyshared with the other users)

The OpenID provider will generate the followinginformation for the user:

(1) An OpenID URI(2) An OpenID username(3) An OpenID public key

After the registration is complete and the user visits theOpenID relying party website, they will be redirected tothe OpenID provider URI, and the user will be asked toprovide authentication. Figure 5 depicts the interface pageused to input the user credentials.

The second component of this authentication scheme willbe a secure application, OpenID_DeskApp, running at theOpenID user’s machine. This would help to coordinate thehandshake between the OpenID user and the provider uponthe authentication request. It is a background application run-ning on the user’s machine and listening to some specificport for authentication requests from the OpenID provider.Figure 6 depicts the OpenID DeskApp interface.

The OpenID provider and OpenID_DeskApp play theirparts in ensuring secure password-less authentication forthe OpenID user to the OpenID provider. Both the applica-tions at the OpenID provider and OpenID user’s end carryout the authentication scheme proposed earlier, where theOpenID provider acts as the challenger and sends out a chal-lenge to the OpenID_DeskApp, and the OpenID_DeskAppacts as a respondent and sends out the response messageson behalf of the OpenID user. A mutual authenticationconducted by the application based on the information pro-vided by the OpenID user at both ends ensures a successfulauthentication of the OpenID user to the OpenID provider.All of the messages communicated between the two applica-tions will be based on standard http messages containingcontents defined in the authentication scheme.

7. EVALUATION OF PHISHINGPROTECTION SCHEME

The following sections will discuss the different scenariosfor phishing attacks in Section 4 and elaborate on howthe proposed solution protects the OpenID user fromrelying party initiated phishing attacks.

7.1. Case 1

Case 1 describes the scenario when the user is providedwith a fake but identical user interface (a replica of theoriginal website) to enter his or her authentication creden-tials. The whole scheme is based on the OpenID relyingparty, which, after receiving the user credentials and theirverification, redirects the user to a phishing (fake) website.



The scheme proposed in this paper provides an authenti-cation mechanism that is not based on a password but onpublically known entities, and the authentication relies on achallenge-response mechanism. This eliminates the need toprovide a shared secret to the provider, and the communica-tion is encrypted and properly protected to ensure messageintegrity. This eliminates the threat of phishing from theOpenID relying party. If it launches a MITM attack, it willbe of no use because the information is temporary and al-ready known. In other words, if the OpenID provider phishesand presents the user with a fake replica website, it will notget the user’s permanent username or password, but only auser name and public key that are already publically known.If the attacker tries to launch aMITM attack, it will be hard tolaunch because the protocol is based on nonce Nidu and Nidp.These provide security at both ends using IPidu.IPidp, whichare the destination and source IP addresses.

Moreover, even if the attacker accepts the fact that itwill not get anything substantial out of forging the OpenIDproviders interface and decides to move on to impersonat-ing the OpenID provider in the authentication protocol, byperforming the entire hand shaking protocol at its end, itwill still be unable to get any information that it coulduse in order to impersonate the user in the future. Follow-ing the entire protocol, if the OpenID provider generates arandom R and the other attributes in the message, it willnot be able to be successful for two reasons. First, becausethe protocol is based on the secrecy of the private keys foreach entity in the communication; the fake OpenIDprovider will never be able to forge the private key of thetrue provider. Second, because no permanent secret isbeing shared at any time, and the only secret is temporary(R). Thus, if an attacker masquerades as a provider to auser in a MITM attack, all they will get in response tothe random R′ will be the R′ for its own generated R.

7.2. Case 2

As discussed in Section 3, scenario 2 is a slightly advancedversion of the case 1 attack, where the attacker, after ana-lyzing the OpenID URI of the user, dynamically creates afake OpenID provider interface and provides it to theOpenID user. As in case 1, the proposed authenticationprotocol protects the user from such an attack with thesame justifications as provided earlier. This attack will beimpossible for an attacker to conduct because they willface the problem of creating the correct secret S that thetrue OpenID provider had generated and shared with theOpenID user. Moreover, as discussed in case 2, even ifthe attacker can somehow identify the shared secret Sand is able to proceed with the authentication, at the endof a successful authentication what the attacker will getin response will be the same random value R that it hadgenerated, thus making the entire effort futile.

In both of the aforementioned specified cases, thescheme is successful in ensuring that no theft of an OpenIDuser’s identity could be performed, by ensuring that at


every stage of the protocol no user identifiable informationis communicated insecurely or entered by the OpenID user.

7.3. Case 3

As discussed in Section 3, scenario 3 is unique in naturebecause it focuses less on a technically based attack andmore on human behavior, specifically the common behaviorof using a username and password as tools for identifyingand authenticating people that has developed over approxi-mately two decades of Internet and computer usage. Al-though the best solution to such an attack is a thoroughunderstanding and changes in the behavior of the end userthrough continuous awareness, the proposed schemeremoves the possibility of such an attack by having no pass-word or any other shared secret that identifies a user to theprovider, at any stage in the protocol. Rather, the entireauthentication scheme is based on public and/or securelyencrypted and verifiable messages being communicatedbetween the two parties without any shared secret beingasked to be revealed to the OpenID provider by the user.Therefore, because there are no passwords involved, evenif the attacking relying party presents an interface to the userthat asks for a username and password pair, rather thanasking for its OpenID URI, the user will have nothing toshare with the attacker except for a few public entities(username and user’s public key), which they already know.

8. CONCLUSIONS AND FUTUREWORK

OpenID systems are widely being devised by variousvendors because of their flexibility and ease of use incyberspace. They also provide significant benefits at theuser end in terms of authentication by eliminating the needto repeatedly enter user credentials. On the other hand, thewidespread use of this technology also depends on efficientsolutions for the security and reliability of this mechanism.This paper addressed one such architectural weakness ofOpenID systems that may cause phishing attacks. Thepaper proposed and provided implementation details of ananti-phishing scheme based on publically known entitiesand randomly generated challenge responses to counter andreduce the possibility of man-in-the-middle and phishingattacks. It should be noted that such a solution will help toreduce the possibility of these attacks, but a comprehensivesolution in terms of controls would also be required for trust-worthy use. Such a control framework would help to addressvarious unattended issues, such as operational, managerial,and interrelated collaboration in a complete environment.The future work in this research will involve the develop-ment of such a framework to help to define controls forvarious aspects of the trustworthy implementation of anOpenID environment, where portability, reliability, trust,and security can be properly ensured.


ACKNOWLEDGEMENTS

The authors would like to extend their sincere appreciation tothe Deanship of Scientific Research at King Saud Universityfor its funding of this research through the Research GroupProject no. RGP-VPP-214. The authors would also like tothank the National University of Sciences and Technology,Islamabad, Pakistan, for its support during the research.

REFERENCES

1. Volchkov A. Revisiting single sign on: a pragmaticapproach in a new context[J]. IEEE IT Professional2001; 3: 39–45.

2. Erdos M, SCantor M. Shibboleth architecture technicaloverview working draft 02[Z]. Shibboleth Project, 2005.

3. La JC. Shibboleth 2 implemented protocols andprofiles [Z]. Shibboleth Project, 2009.

4. Microsoft .Net Passport Review Guide[Z]. 2008.

5. Liberty Alliance. Liberty ID-FF architecture overviewv1.2 [Z]. Liberty Alliance Project, 2006.

6. OASIS. Assertions and protocol for the OASISsecurity assertion markup language (SAML) V2.0.OASIS Standard, 15 March 2005.

7. The Kerberos network authentication service (v5).September 1993. Available from: http://tools.ietf.org/html/rfc1510 (accessed on 23-05-2012).

8. Distributed identity: Yadis. May 2005. Availablefrom: http://community.livejournal.com/ljdev/683939.html (accessed on 09-12-2012).

9. Openid sponsoring members. Available from: http://openid.net/foundation/sponsoring-members/ (accessedon 09-12-2013).

10. Tsyrklevich E, Tsyrklevich V. OpenID: single sign onfor the Internet. Black Hat USA Briefings andTraining, Las Vegas, July 28–Aug 2, 2007.

11. Charas M. Security in OpenID. An overview ofOpenID from a security perspective. Master of ScienceThesis, 2009.

12. Oh H-K, Jin S-H. The security limitations of SSO inOpenID. ICACT, Feb 17–Feb 20, 2008.

13. Qaemi Mahmoodzadeh M, Abbas H. Password-lessauthentication framework for OpenID systems tocounter phishing attacks. The 2012 IEEE Asia-PacificServices Computing Conference, Guilin, China,December 6–8, 2012.

14. Lee HJ, Jeun IK, Chun K, Song J. A new anti-phishingmethod in OpenID. In SECURWARE ’08: Proceedingsof the 2008 Second International Conference onEmerging Security Information, Systems and Techno-logies, Cap Esterel, France, 2008; 243–247.

15. Feng Q, Tseng K-K, Pan J-S, Cheng P, Chen C. Newanti-phishing method with two types of passwords inOpenID system. 2011 Fifth International Conferenceon Genetic and Evolutionary Computing (ICGEC),Aug. 29, 2011–Sept. 1, Xiamen, China, 2011; 69–72.

16. Huang C-Y,Ma S-P, Chen K-T. Using one-time passwordsto prevent password phishing attacks. Journal of Networkand Computer Applications 2011; 34(4): 1292–1301. ISSN1084-8045, doi: 10.1016/j.jnca.2011.02.004

17. Munkhdalai T, Li M, Yun U, Namsrai O, Ryu KH. Anactive co-training algorithm for biomedical named-entity recognition. Journal of Information ProcessingSystems 2012; 8(4): 575–588.

18. Chen C-W, Tsai Y-R, Wang S-J. Cost-saving keyagreement via secret sharing in two-party communi-cation systems. Journal of Convergence 2012; 3(4):29–36.

19. Mohanty S, Majhi B. A strong designated verifiableDL based signcryption scheme. Journal of InformationProcessing Systems 2012; 8(4): 567–574.

20. Fan C-I, Lin Y-H. Full privacy minutiae-basedfingerprint verification for low-computation devices.Journal of Convergence 2012; 3(2): 21–24.

21. Viswanathan V, Ilango K. Finding relevant semanticassociate paths through user-specific intermediate enti-ties. Human-Centric Information Sciences 2012; 2: 9.

22. Malik AJ, Shahzad W, Aslam Khan F. Hybrid binaryPSO and random forests algorithm for networkintrusion detection. Security and CommunicationNetworks (Wiley) in press. doi: 10.1002/sec.508

23. Peng K. Efficient and general PVSS based on ElGamalencryption. Journal of Information ProcessingSystems 2012; 8(2): 375–388.

24. Obaidat MS, Zarai F. Novel algorithm for securedmobility and IP traceability for WLAN networks.Journal of Convergence 2012; 3(2): 1–8.

25. Aikebaier A, Enokido T, Takizawa M. Trustworthygroup making algorithm in distributed systems.Human-centric Computing and Information Sciences2012; 1(6): 1–15.

26. Islam R, Abawajy J. A multi-tier phishing detectionand filtering approach. Journal of Network andComputer Applications Available online 7 June 2012.ISSN 1084-8045, doi: 10.1016/j.jnca.2012.05.009

27. Mao C-H, Lee H-M, Yeh C-F. Adaptive e-mails inten-tion finding system based on words social networks.Journal of Network and Computer Applications2011; 34(5): 1615–1622. ISSN 1084-8045, doi:10.1016/j.jnca.2011.03.030

28. Beginner’s guide to OpenID Phishing. Available from:http://www.marcoslot.net/apps/openid/ (accessed on14-05-2012).


http://www.marcoslot.net/apps/openid/


29. Rivest R, Shamir A, Adleman L. Amethod for obtainingdigital signatures and public-key cryptosystems. Com-munications of the ACM 1978; 21(2): 120–126.

30. ElGamal T. A public-key cryptosystem and a signa-ture scheme based on discrete logarithms. IEEETransactions on Information Theory 1985; 31(4):469–472.


31. Federal information processing standard (FIPS)180-3: se-cure hash standard. Information Technology Laboratory,National Institute of Standards and Technology, 2008.

32. Bringer J, Chabanne H. Embedding edit distance toenable private keyword search. Human-centric Com-puting and Information Sciences 2012. doi:10.1186/2192-1962-2-2.

Documents

Identifying an OpenID anti-phishing scheme for cyberspace