Computers & Security (2004) 23, 478e488

www.elsevier.com/locate/cose

Peer-assisted carrying authentication (PACA)

Hassan A. Artail)

Department of Electrical and Computer Engineering, American University of Beirut, P.O. Box 11-0236,Riad El-Solh, Beirut 1107 2020, Lebanon

Received 13 November 2003; revised 8 April 2004; accepted 20 April 2004

Abstract In this paper we present a method for password recovery through theemployment of multiple Web servers, and which we name Peer-Assisted CarryingAuthentication (PACA). The paper starts by highlighting the vulnerabilities of thecommonly used techniques for password recovery, namely the questioneanswer ap-proach. It then proceeds to providing a general coverage of the proposed approachand discusses the details and offered solutions to issues that relate to implementa-tion and security. We present a software application that we developed for proof-of-concept and as a tool for class-based experiments. These were conducted toshow the ability of users to hack accounts of other users with whom they have orhad some kind of relationship and test the effectiveness of piecewise password re-covery. The results indicate that people who are close to others can often guesssome of their passwords correctly and therefore, are able to hack their computeraccounts. It is shown that PACA makes the hacker’s job very difficult through themultiple peer authentication mechanism. In this regard, the findings could be usedto set a lower bound on the number of peer sites for authenticating users.ª 2004 Elsevier Ltd. All rights reserved.

KEYWORDSPassword recovery;Authentication;Privacy;Security;Web servers

Introduction

Nowadays, Internet users often find themselvesusing passwords for sites they do not access fre-quently. Furthermore, due to the increasinglygrowing awareness of security issues, users arebeing encouraged to come up with long and charac-ter-and-digit mixed passwords (Chin, 2003;Shimonski, 2002; Shinder, 2002). This and thefact that longer and more complex messages areharder to memorize and easier to forget (Miller,

) Tel.: D961-1-350-000x3459/3520; fax: D961-1-744-462.E-mail address: hartail@aub.edu.lb.

0167-4048/$ - see front matter ª 2004 Elsevier Ltd. All rights resedoi:10.1016/j.cose.2004.04.003

1956), more users are forgetting their passwords,making it very important for effective and securepassword recovery techniques to be developed.

A recent survey was conducted at the AmericanUniversity of Beirut (AUB) to learn about possiblerelationships between password complexity andforgetting passwords. Over 700 students and staffmembers answered the survey that asked how fre-quently passwords are used, what password struc-ture was used, and whether the passwords wereforgotten within a period of one year. The surveysupplied four usage categories and four structurecategories as shown in Table 1.

Fig. 1 shows the percentage of respondentswithin each usageestructure category (see Table 2)

rved.

Peer-assisted carrying authentication 479

Table 1 Password categories specified in the survey

Type Name Explanation Example

Usage Daily Used on a daily basis.Weekly Used once a week, on average.Monthly Used once or twice per month.Seasonally Used less often than once per month.

Structure Random Totally or nearly random, with no meaning. K3cf&na0Semi-structured One part carries a meaning while the other is

made up of arbitrary numbers and/or characters.carmen150

Structured Concatenation of two or more meaningful strings. MybighouseMeaningful Single meaningful string. Airplane

who forgot their passwords at least once withina span of one year. The results show that as thecomplexity of the password increases and the fre-quency of use decreases, the number of forgettingincidents increases.

A number of techniques are being used todaywhere the majority employs a questioneanswerapproach that asks the user about personal andfavorite things, people, or places. Fig. 2 presentsthe data of a survey involving 37 commonly usedweb sites including portals (e.g. yahoo.com),e-mail (e.g. webmail.com), government (e.g. saas.gov.uk), e-business (e.g. philippineairlines.com),higher education (e.g. eperc.mcw.edu), and otherweb sites. All shown questions relate to personalinformation that users may share with others, es-pecially with whom they develop relationships.This makes it possible for people who are able toimpersonate such users to get hold of theirpasswords using the questioneanswer recoverytechnique.

Some interesting data that tally the number ofpassword-related cases on a monthly basis sinceMay 1999 was obtained from the Computing and

Figure 1 Percentage of users who forgot their pass-words in each usageestructure category (see Table 2).

Networking Services (CNS) department at AUB.The data are shown in Fig. 3. The lower curve cor-responds to cases where students and staffrequested password recovery from the system(using the questioneanswer technique). The uppercurve relates to cases where users requesteda password reset from the administrator. Thedata do not reveal the reason for the resets butreportedly, many users had concerns about theiraccounts being hacked by people who got holdof their passwords. The apparent correlation be-tween the two types of data, i.e. password recov-eries and password resets, may suggest that someof the ‘‘stolen’’ passwords were acquired throughthe recovery system (refer to the above discussionabout the results of the Web site survey). We notethat about 7000 students attend AUB each semes-ter and close to 1000 staff members work at theuniversity.

A fairly recent technique was proposed that helpsusers recover the entire password given that theyremember a certain percentage of it (Frykholmand Juels, 2001). However, the often-complexpassword must have been derived by the systemfrom a sequence of simpler passwords. Otherapproaches specialize in recovering informationthat was key-encrypted with a now-lost or

Table 2 Number of users who answered the survey,classified according to how often they use theirpasswords and the password structure [some users fitin more than one category (reported using more thanone password)]

Daily Weekly Monthly Seasonally Total

Random 91 28 16 8 143Semi-

structured116 61 92 24 293

Structured 88 45 32 16 181Meaningful 28 22 39 9 98Total 323 156 179 57 715

480 H.A. Artail

misplaced key (Smith et al., 2000) or in recoveringthe key itself from applications (Held, 1998).

A GSM-based authentication method was pro-posed in Khu-smith and Mitchell (2002) and relieson the uniqueness of the long-term secret key pro-grammed into the SIM card of the GSM-enabledphone. During the registration phase on the server,the user supplies the GSM phone number, whichgets communicated to a GSM authentication cen-ter of the subscriber’s home network operator.This latter is the organization with whom thesubscriber has some kind of contractual arrange-ment for the provision of service, and for whichhe or she pays a fee. For password recovery, theuser submits the phone number to the server,

am ehT

uoy fo ekr

rac tsrif ekib ro

gih ruoYh

hcs tocsa

m loo

etirovaf ruoYkaerb(

saft

doof )

ad ruoYhtrib fo e

mit/y

s'rehtaf ruoYe

man

iH/yra

mirP/hg

hcs tsriFn looa

em etirovaf ruoYco

rol

tic ruoYy

htrib fo

F( ruoYtir ova

tsriF/e)

s'tep 'g o

D(e

man )s

Your choiceYour mother's maiden name

8%

6%6%5%3%2% 3%2% 4%

10%12%

2%2%2%

uops ruoY'ess

eman tsrif/elddi

m etirovaf ruoYte

ache

r'sna

me

Your

(Chi

ldho

od)h

ero

srehtO

,f ,.g.e av

otiurf etir

33%

Figure 2 Questions asked to users for password re-covery. The size of each pie sector indicates the rate ofoccurrence among the 37 surveyed web sites.

0

100

200

300

400

500

600

700

800

900

1,000

stnedicni fo rebmu

N

05 09 01 05 09 01 05 09 01 05 09 01 05 09 1999 2000 2001 2002 2003

Date of occurrence

Figure 3 Password-related cases for the past 4.5 yearsat AUB. The lower curve relates to user-initiatedpassword recoveries while the upper curve relates topassword resets initiated by system administrators basedon user requests.

which then contacts the authentication centervia the mobile phone to authenticate the user.The main disadvantage of such an approach isthe need for a prior agreement between the serveradministration and the mobile service provider tosupport the protocol. Furthermore, this methodwill likely involve additional fees to be paid bythe user for getting the service.

The idea behind our work originated from thework on Proof-Carrying Authentication (PCA)(Appel and Felten, 1999), which is based on theprinciple of proof-carrying codes (Necula, 1997),whereby the client desiring access must constructa proof and present it to the server, which will inturn check it. In this method, the client generatesproofs from pieces of a security policy that wasdistributed across arbitrary hosts.

Our approach, which we name Peer-AssistedCarrying Authentication (PACA), works by confirm-ing the user’s identity by means of successful au-thentications made by a group of servers that theuser has previously registered with and presumablyaccesses frequently. As in PCA, PACA places theburden on the client, but instead of constructingthe proof from a distributed policy, the client mustbe authenticated by hosts that implement theirown policies and which are known by the serverand chosen by the client during registration. Forclarity, we refer to the server, on which the userhas forgotten the password and wishes to recoverit, the authentication server (or simply, the server)and to the other servers as the peer sites.

The remainder of this paper is organized as fol-lows. In the next section we present the details ofthe approach, including the protocols for registra-tion and recovery, then go a step further to discusshow security and implementation issues are ad-dressed. Then we introduce an application thatwas developed to test the approach and whichwas used as a tool in three class-based experi-ments that are described in the section beforelast. We finish the paper with concluding remarksin the last section.

Details of the approach

The user originally opens an account or creates alogin ID on a given Website (authentication server)by choosing a username and a password (creden-tials) as in normal registration. However, if PACAregistration is specified, she may be prompted toalso specify websites ( peer sites) that she uses fre-quently. When she wishes to recover the forgottenpassword, she will be prompted to iteratively login

Peer-assisted carrying authentication 481

to the peer sites for authentication. The loginsallow the server to confirm her identity throughreceiving user-related information from the peerservers. Two methods are implemented for pass-word recovery. The first sequentially feeds theuser with pieces of the password in a manner thatcorresponds to the responses received. The secondwaits until all the responses from the peer sites arereceived before giving the whole password to theuser in one shot.

The implementation gives rise to certain issuesthat are related to privacy and overhead. Further,since PACA is supposed to be used with currentwebsites, it cannot rely on a totally new protocolsuite but has to work with current and future Inter-net Infrastructures. These issues and constraintsare addressed below but first we shall presentthe general rules ( protocol) that make up theapproach and which fall into two categories: regis-tration and recovery.

Registration

The registration protocol comprises the followingsteps:

1. The browser contacts the server to requestPACA registration. If the server does notsupport it, the registration will be carried outusing conventional means.

2. The server prompts the user to enter one ormore peer Website URLs. These are sites thatthe user has accounts on and remembers theirpasswords.

3. After each URL is supplied by the user, theserver redirects the client to the peer site’spage in accordance with the URL. Therefore,the interaction between the client and thepeer site takes place without the involvementof the server and thus, protecting the peersite’s login information from being exposed.

4. The peer site checks the provided usernameand password and if found, it sends the clienta peer authentication that contains user-specific data along with the server’s URL anda number representing a fraction of thepassword (i.e., 0.25). The number of peersites, which is determined by the user, alongwith optionally entered weights, determinethe fractions (which add up to 1) correspondingto the sites.

5. After contacting each peer site, the receivedauthentication and the corresponding peer siteURL are forwarded to the server for storage. Itmay be possible that one or more specified

peer sites do not support PACA or do notauthenticate the user. In such cases, the userdata will reflect this fact, which allows theserver to react by prompting the user tospecify alternative sites or indicate the failureof the registration process. The explanation ofthe PACA registration protocol is summarizedin the diagram of Fig. 4 and as pseudo code inthe Appendix at the end of the paper.

Recovery

The password recovery protocol of PACA is madeup of the following steps:

1. The client connects to the server on which shehas an account and requests password recoveryafter providing a username.

2. If the username is found, the server checks ifthe account was registered using PACA. If it isthe case, two possible paths may be followed,based on the registration data:a. the user provides the peer site URLs which

then get checked by the server to determineif they match what was provided at the timeof registration or,

b. the server itself provides the URLs that werespecified during registration.

1: Client requests PACA registration from server and enterspersonal info.

2: For all peer sites (i=1, 2, …, N)2-i-1: Server prompts client to specify peer site’s URL2-i-2: Client requests authentication from peer site 2-i-3: Peer site sends user-specific data

tneilC

…

1

PeerSite 1

PeerSite 2

3-1-2

2-2-2

3-2-2

…

-2N

2- -2N

3-

1-2-2 -2N

1-1-1-2

2-1-2

PeerSite N

Authentication Site (Server)

Figure 4 Summary of the PACA registration process.The filled dots denote the start of the steps while theempty dots indicate their completion. After the conclu-sion of each step, the server prompts the user for a newURL until a blank URL is entered.

482 H.A. Artail

3. The client connects to each peer site andprovides it with a username and a password.

4. Each peer site sends to the client user datathat embeds the authentication status and theuser account’s information.

5. The user data, peer site URL, and the passwordfraction are then shipped to the server. Here,two cases exist:a. Piecewise recovery (chunking): after each

peer authentication, if the user data is con-sistent with the data received at registrationtime, the server sends to the client the partof the password that corresponds to thefraction and the peer site. The user is thengiven the choice to skip the remainder of theprocedure in case she remembers the entirepassword after receiving parts of it. It isnoted here that the parts that make up theentire password follow the same order asthat of the entered URLs during registration.In other words, the first part maps to thefirst peer site specified at registration time,the second part (which immediately followsthe first part) maps to the second peer site,and so on. It follows that during recovery,the user will not get the chunks in contiguousfashion unless she specifies the peer siteURLs in the same order as when they werespecified during registration. The server maybe programmed to supply the user with thepositions of the different chunks within thepassword or leave it up to the user to figureout how to put the pieces together.

b. One-shot recovery: after all the peer authen-tications have successfully taken place, theserver sends the client the entire password.If any of the authentications fails, the wholepassword recovery procedure fails.

The goal behind chunking is to provide the userwith an option for fast password recovery wherebythe server discloses chunks of the password afterconsecutive successful peer authentications. PACAexploits basic characteristics of the human memo-ry system, most important of which is the contextof the subject to remember (Bensinger, 1998).Depending on the password’s complexity and fa-miliarity to the user, the latter may recall the pass-word after the first or few chunks are supplied.The above protocol is summed up in the diagramof Fig. 5 and the Appendix.

Issues

The simplicity of the protocol gives the PACA ap-proach an added value. Still, some resulting issues

need to be addressed, namely privacy, overhead,and compatibility.

PrivacyIn order to protect the user’s credentials on thepeer sites, a method was designed based on theexchange of codes, representing user data. Thisis used in conjunction with the man-in-the-middletechnique to enable the server to coordinate com-munications between the client and the peer sites.More specifically:

1. After the user requests password recovery, theserver sends the client a special code forinitiating peer authentication.

2. The code is sent from the client to the peersite along with the user-supplied credentials ofthe account on that site.

3. The peer site performs the authentication andsends to the client some form of user data. Thisdata consists of a hash value that uniquelyrepresents the usernameepassword pair of theuser’s account in addition to the site’s URL.

4. The user data is passed to the authenticationserver.

In the above setup, the authentication serverand peer site connect through a form of virtualnetwork where they communicate through the cli-ent. No breach takes place even if the user is al-lowed to decode the transmitted data betweenthe peer sites and the server since the sent datais user-specific that does not reveal the actual cre-dentials of the accounts on the peer sites.

An apparent issue that concerns user privacy isthe storage of peer site URLs on the server. Thisenables the administrators of the peered sites toknow what other sites users are registered with,thus giving them an opportunity to learn aboutuser interests. This is a trust issue that is similarto the situation when users trust the sites on whichthey are opening accounts and disclosing personalinformation. We can think of sites that supportPACA as having an implicit agreement, whichshould bar them from unauthorized use of userdata without the user’s consent. Additionally andsimilar to current practice, the peered sites maybe set up to ask users during registration for autho-rization about what is allowable relative to the useof user data, including the site URLs.

OverheadSeveral concerns may be brought up relative tooverhead in PACA. Most importantly are those re-lated to storage space, resource utilization, andrecovery process time.

Peer-assisted carrying authentication 483

1: Client enters username and requests password recovery2: For all peer sites (i=1, 2, …, N)

2-i-1: Client provides URL of peer site, or2-i-2: Server provides URL of peer site 2-i-3: Server checks against registration records 2-i-4: User logs into peer site 2-i-5: Peer site sends authentication hash code to server2-i-6: Server sends client corresponding portion of password (if

authentication was successful)3: Server sends client complete password (in the case of one-shot recovery)

…

Authentication Site

1

PeerSite 1

PeerSite N

-2N

5-5-1-2

4-1-2

…-2N

4-

Checking & Processing

-2N

6-

-2N

1--2N

3-

if (+) response

…

1

PeerSite 1

-2N

4-5-1-2 - 2N

5-

…

Checking & Processing

6-1-2

2-1-2 -2N

6-

-2N

2-

tneilC

tneilC

if (+) response

3-1-21-1-2

6-1-2

3

4-1-2

PeerSite N

Authentication Site

Figure 5 Diagram summarizing the PACA recovery process: client provides the peer site URL (left) or server providesthe URL (right). Step 3 (far right) applies if piecewise recovery is not specified during registration. The dashed linesindicate process flow internal to the server or the client.

With respect to disk space, there is an additionalrequirement since for every user there are associat-ed peer website names and user data that must bestored. PACA minimizes this issue through the use ofa number, which is the product of a one-way hashfunction of the username, password and peer web-site. Mathematically, this can be expressed ashðusername;password;URLÞ, which guarantees itsuniqueness. The hash value is sent to the browseralong with the URL. If this is part of registration,then the browser adds a floating-point value repre-senting a fraction of the password to the data re-ceived from the peer site. The combined data isthen sent to the server after each peer authentica-tion. In the case of recovery, the data receivedfrom the peer site are sent as is directly to theserver. In all, each user requires additional spaceto store the hash code, URL, and password fractionfor each peer site. This is not very taxing for theserver as the extra space is mainly taken up bythe URLs of the peer servers (hash code and pass-word fraction are two numbers).

Besides space, the issue of additional resourceutilization, from the point of view of the peer site,needs to be addressed. After all, the peer site is

offering a service to a user who is not asking forthe site’s intended services after the login. We ar-gue that there are two motivations for encouragingsystem administrators to configure their servers asto offer PACA services to requesting servers. First,the users who are being authenticated have localaccounts and have either used the peer site’s serv-ices or will use them in the future. Second, thepeer site itself may request PACA authenticationfrom the server that is requesting this same servicenow. Supporting PACA can be thought of as anagreement between cooperating servers whereall members gain in the long run.

A third issue that may be brought up is the timeit takes to recover the password. The server redi-rects the user to two or more sites where she mustsuccessfully login in order to retrieve her forgottenpassword. It is reasonable to assume that userswho end up forgetting their passwords and wantthe server to reveal it to them are willing to gothrough this process that may take them a minuteor more to complete. We note additionally thatthe user could choose to use chunking during regis-tration for possible time savings during passwordrecovery time.

484 H.A. Artail

CompatibilityThe implementation of PACA is at the applicationlayer and thus, no communication protocol needsto be altered. The protocol that was used to testand verify PACA was HTTP/1.1 (Krishnamurthyand Rexford, 2001; RFC 2616), where two methodswere originally devised to implement the authenti-cation codes while the rest of the data was sent aspart of the data packet. In the first method thecodes were directly transmitted in the requestheader as the request type. This method is incom-patible with HTTP/1.0 and would require the def-inition and identification of the codes. The secondmethod used is more compatible and offersgreater flexibility. The codes were sent in the re-quest header under the title ‘‘Optional’’, whichmakes it easy for a previously configured serverto look for and correctly interpret them. A thirdapproach, which was used in the implementationof the final version, did not involve stuffing any ad-ditional information in the HTTP header but madeuse of cookies to transfer information between theserver and peer sites via the client. This approachis detailed in the following section.

Implementation

First, we explain how a typical session is carriedout right from the start. From the point of viewof data exchange between the server and peersites, the registration and recovery processes arethe same and hence, it suffices to cover the regis-tration phase.

After the user (client) supplies the registrationinformation to the authentication server and selectsPACA, she is prompted with a form to enter the URLof the first peer site. Once the URL is entered andthe form is submitted, the server redirects thebrowser to the corresponding peer site after writinga cookie on the client that is intended for the peersite (e.g., by setting the cookie’s Domain propertyin ASP.NET to the entered URL). The cookie con-tains the name of the server, a request for authen-tication, and the server’s session id. When thebrowser switches to the peer site, the cookieinformation is transferred in the header of theHTTP packet, thus allowing the login applicationon the peer site to identify the request forauthentication. After reading the cookie informa-tion, the peer site deletes the cookie (e.g., settingthe Expired property in ASP.NET to true). Once theuser enters her username and password, the siteredirects the browser to the server after writinga cookie on the client that is intended for the

server. This cookie contains the echoed server’ssession id, the hash value, and the URL of thepeer site. As a last step, the server reads the cook-ie’s information from the header of the incomingHTTP request and deletes it afterwards. This en-tire process is repeated until the user signals itscompletion (in our particular implementation, byentering a blank URL).

The testing involved, in addition to the authen-tication server and the client machine, five peersites, which were set up on Dell personal worksta-tions that are part of the Engineering Multimedialab at AUB. The machines were running WindowsXP and 2000 and networked using a 10 Mbps back-bone. The applications running on the server andpeer sites were both developed in ASP.NET andC# and serviced by Microsoft’s Internet Informa-tion Server (IIS). The snapshots of Figs. 6e10 areprovided to give an overview of the developedsystem.

Fig. 6 illustrates the first step in the registrationprocess where the user has specified ‘‘lifeonmars’’as her password. The two indented check boxesallow the user to exercise control over the levelof security during password recovery. The first ofthe two requires that the user, not the server, sup-plies the peer site URLs when password recovery isneeded. The second box can be used to allowpiecewise password recovery or to ensure thatthe user is authenticated by all peer sites beforethe password is unveiled (when the box isunchecked).

Fig. 7 shows the second step of registration dur-ing which the peer sites are specified and the useris authenticated by each one of them (Fig. 8).Fig. 9 presents the recovery interface. It can benoticed how the order of the peer sites does nothave to match their order during registration.Finally, Fig. 10 presents a screen that was

Figure 6 Interface that allows users to specify PACAregistration and recovery options.

Peer-assisted carrying authentication 485

developed to show the activity of the server andthe different actions that take place. Note how-ever that even though many events took placebetween registration and recovery, the code waswritten not to display them on the shown window.

Experiments

For testing purposes and since it is not possible toforce users to forget their passwords, we used ex-periments based on familiarity (or unfamiliarity)among students to simulate forgetting (or remem-bering). The logic behind this is that a student whois very close to another student will likely knowa considerable amount of personal data abouthim, including answers to questions such as thoseshown in Fig. 2. This knowledge enables thestudent to make guesses, many of which are trueregarding possible passwords that her friend haschosen for computer accounts. This fact is espe-cially true for students since they spend consider-able time together in classrooms, laboratories, andeven outside campuses. The work done on humanmemory modeling supports our proposition for

Figure 7 Second step of PACA registration where theuser logs in to the specified peer sites.

Figure 8 Interface for logging into the peer sites.

using familiarity to simulate memorizing and for-getting. This is explained through a comparison inTable 3.

Three experiments were performed by employ-ing students. The first two focused on testing theeffectiveness and the usability of the system butadditionally, the first experiment was used toverify our intuition that user passwords (mostlythose that carry meanings) can be guessed cor-rectly by people who possess personal data aboutthe user. The purpose of the third experimentwas to test the user acceptance of the system.

For the first two experiments, students tookpart of the experiments through two classes they

Figure 9 Password recovery interface for logging intothe peer sites.

Figure 10 Server interface designed to show theregistration and recovery progress.

486 H.A. Artail

Table 3 Similarities between memory and familiarity

Memory Familiarity

Enforced by redundancy (Miller, 1956) Increased friendship involves more frequent interactions.Enforced by capturing interests

and related data (Nakata, 1999)Increased friendship involves learning about others’interests and sharing individual knowledge.

Weakened by time decay (Reed, 1982) Friendship is weakened by long gaps between interactions.Weakened by interference

(Waugh and Norman, 1965)Increasing the number of friends reduces the timeavailable for one-on-one interactions, potentially weakeningindividual friendships.

were taking with the author. The first was a secondyear undergraduate class with 115 students whilethe second was a graduate class of 28 students.The undergraduate students were divided into 34groups while the graduate students were dividedinto 9 groups. The group size was between twoto five individuals and the groups were formedbased on student acquaintance with each other,which was determined after a questionnaire (seeTable 4).

Each student was required to register on aPACA-enabled authentication server using fivepeer sites of his or her choice. Within each group,students were then asked to try to hack the ac-counts of all other students in the same group onthe peer sites and on the server. Since each stu-dent engaged in hacking one or more accounts,for the experiment results, we define a trial as theprocess of one student trying to hack one account.

Experiment 1

In the first experiment, students were asked tohack the peer sites that were provided by theserver. Piecewise recovery (chunking) was not en-abled and hence, students needed to get into allpeer sites in order to hack the server’s account.

Fig. 11 shows the percent of trials that resultedin one, two, or more peer site accounts (out offive) being hacked. In the VF category, less thanthird of the trials resulted in guessing the passwordof one peer site account but the number droppedquickly as the number of sites increased. Although

Table 4 Student group composition

Numberof groups

Number ofstudents

Relationship betweengroup members

6 15 Very Close Friendship (VF)11 38 Close Friendship (CF)17 59 Occasional Friendship (OF)9 31 No Friendship (NF)

one student was able to make it very close (loggedinto four sites), no one could hack all fiveaccounts. In the CF category, no one made it be-yond three accounts while for the other catego-ries, the numbers were insignificant. Althoughthis is a limited case study, it gives an idea ofthe general trend and of the need to specifymore than just a couple of peer sites duringregistration.

Experiment 2

For the second experiment, students were giventhe username and password pairs to their groupmembers’ accounts on all peer sites and wereasked to guess the password of the server’s ac-count after each piece of the password wasdisclosed (chunking was enabled during registra-tion). One could think of the students in the fourcategories attempting to guess the server’s pass-word after each chunk, as users who forgot theirpasswords to varying degrees and are trying to re-member them after each hint. Hence, the experi-ment can be used to test the speed at whichpasswords can be recovered using piecewise re-covery. The results in Fig. 12 imply that giventhe user’s degree of familiarity with the specified

0%

10%

20%

30%

40%

1 2 3 4 5Number of Hacked Peer Sites

%o fS

tude

ntT

raisl

Very Close CloseOccasional No Relation

Figure 11 Percent of student-trials that were able tohack the peer sites. Within each group, each studentattempted to hack the peer sites of the remaining groupmembers’ accounts.

Peer-assisted carrying authentication 487

password at registration time and the password’ssignificance, the incremental help that each chunkoffers either increases or decreases in magnitude.As the original familiarity increases, fewer chunksare needed to remember the password, while inthe opposite case, the trend is inversed.

Experiment 3

The third experiment utilized mostly a differentgroup of students. These are students belongingto four classes that deal with programming andhave weekly lab sessions. Students took part ofthe experiment on a voluntary basis in the com-puter lab and were asked to try PACA and answerthe following four questions after explaining howthe approach works.

Q1. Is PACA acceptable as a password recoverysystem?

Q2. Is PACA advantageous over the existing ques-tioneanswer technique?

Q3. Is piecewise recovery more useful than one-shot recovery?

Q4. Enhancements?

Table 5 shows some details related to the stu-dents and to the outcome of the experiment. It

0%

20%

40%

60%

80%

100%

1 2 3 4 5Number of chunks (out of maximum of 5)

%S

tdu

netT

rials

Very Close CloseOccasional No Relation

Figure 12 Plot that shows the number of student-trialswhere students were able to guess the server’s passwordafter each number of password chunks for each groupcategory.

is noted that out of the 332 students who tookpart in the experiment, only 24 had already beenexposed to PACA. All these students belong tothe graduate class ( fourth row in the table) andwere part of the original tryout of the system, con-ducted five months prior to Experiment 3.

Almost everyone answered Q1 favorably whilethe percentages of those who answered Q2 andQ3 favorably are shown in the table. We may inferfrom the answers to Q2 and Q3 that as users be-come more aware about security issues, theywould tend to favor a system like PACA. In this ar-gument, we assumed that awareness increaseswith experience, e.g., a graduate student is likelyto be more concerned and aware about securitybreaches than a first-year student. As for Q4, manysuggestions dealt with the user interface and onlyone related to security. This suggestion requeststhat the recovered password (or the pieces) besent to the user via HTTPS, i.e., using the SecureSocket Layer (SSL). This can be easily implementedby having the application instruct the Web serverto switch over to HTTPS when wanting to sendthe password.

Conclusion

In this paper a password recovery approach waspresented based on the idea of cooperation be-tween Web servers for user authentication. Theapproach was described in details and an applica-tion that implemented it was presented. Three ex-periments were carried out. The first two suggesta low bound on the number of authenticatingWeb servers to minimize the chances ofunauthorized users getting hold of the password.The third experiment indicated strong acceptanceof the approach among a sizable group of students.The idea behind the approach can be extended tosupport other types of cooperation betweenWeb servers aimed at augmenting their individualcapabilities.

Table 5 Results of the acceptance questionnaire (the averages in the bottom row were obtained by dividing thenumber of those who answered favorably by the total number)

Course name and level No. of students Q2 (%) Q3 (%)

CDD programming (1st year) 192 65 82.3Data structures (2nd year) 67 61 91Software engineering (3rd year) 41 81 61Pervasive computing (graduate) 32 84 53Total/average 332 68 (avg.) 79 (avg.)

488 H.A. Artail

Acknowledgements

The author would like to thank the studentsMackram Raydan, Rami El Mawas, and Nada AbouNaccoul for their help in running the experi-ments and doing the surveys, writing portionsof the implementation code, and reviewing thepaper.

Appendix

Registration pseudo code

Choose username and passwordChoose Peer Authentication optionsWhile a new peer site is specified

Enter peer site URLUser attempts logging in to peer sitePeer site sends authentication dataClient forwards data to server

End whileServer saves data

Recovery code

User enters username and requests passwordrecovery

Server verifies account and PACA registrationFor all peer sites specified in account

If user must provide peer site URLsClient sends user-supplied URL to serverIf invalid URL

Abort recovery processEnd if

ElseServer supplies peer site URL

End ifUser attempts logging in to peer sitePeer site sends authentication data to server

(via client)Server checks data against account informa-

tionIf authentic

If account specifies piecewise recovery(chunking)Server sends password chunk to user

End ifElse

Abort recovery processEnd if

End for

If chunking is not specifiedSupply whole password to user

End if

References

Appel A, Felten E. Proof-carrying authentication. Proceedingsof the Sixth ACM Conference on Computer and Communica-tions Security, Singapore; 1999. p. 52e62.

Bensinger D. Human memory and the graphical password. Tech-nical report. Passlogix Inc; 1998. Available from: http://www.securitytechnet.com/resource/security/hacking/bensinger.pdf.

Chin P. Mum’s the worddeffective methods to protect your pass-words. Intranet J 2003. Available from: http://intranetjournal.com/articles/200108/ic_08_22_01a.html.

Frykholm N, Juels A. Error-tolerant password recovery. Pro-ceedings of the Eight ACM Conference on Computer andCommunications Security (CCS-8), Philadelphia, PA; 2001.p. 1e9.

Held G. Password recovery Windows toolkit. Int J NetworkManagement 1998;8(6):368e70.

Khu-smith V, Mitchell C. Enhancing e-commerce security usingGSM authentication. Technical report, RHUL-MA-2002-3.Department of Mathematics, Royal Holloway, University ofLondon; 2002.

Krishnamurthy B, Rexford J. Web protocols and practice. 2nded. Addison Wesley; 2001.

Miller G. Human memory and the storage of information. IEEETrans Inform Theory 1956;2(3):129e37.

Nakata K. Knowledge as a social medium. New Gen Comput1999;17(4):395e405.

Necula G. Proof-carrying code. Proceedings of the 24th AnnualACM SIGPLAN-SIGACT Symposium on Principles of Program-ming Languages (POPL’97); 1997. p. 106e19.

Reed S. Cognition: theory and applications. Monterey, CA:Brooks/Cole Pub. Co.; 1982.

RFC 2616 for HTTP/1.1.Shimonski R. Create effective passwords. Technical Report. IBM

Corporation; 2002. Available from: http://www-106.ibm.com/developerworks/security/library/s-pass.html.

Shinder D. Scene of the cybercrime. Rockland, MA: SyngressPublishing; 2002 [chapter 7].

Smith M, VanOorschot P, Willet M. Cryptographic informationrecovery using key recovery. Comput Secur 2000;19(1):21e7.

Waugh N, Norman D. Primary memory. Psychol Rev 1965;72:89e104.

Hassan Artail worked as a system development supervisor atthe Scientific Labs of DaimlerChrylser, Michigan before joiningAUB in 2001. At DaimlerChryler, he worked for 11 years in thefield of software and system development for vehicle testingapplications, covering the areas of instrument control, com-puter networking, distributed computing, data acquisition,and data processing. He obtained a B.S. and M.S. in ElectricalEngineering from the University of Detroit in 1985 and 1986,respectively, and a Ph.D. from Wayne State University in1999. His research is in the areas of Internet and Mobile Com-puting, Distributed Computing and Systems, Mobile Agents,and Data Presentation.