joseph bonneau - cl.cam.ac.uk€¦ · no tls, 6 char. min. password, personal knowledge questions...

User authentication on the web

Joseph [email protected]

Computer Laboratory

SOCIALNETS workshopNovember 18, 2010

J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 1 / 10

Looming authentication challenges

1 The old world2 The emerging world


WEIS 2010: Large study of password deployments

“Identity” websites



“E-Commerce” websites



“Content” websites


WEIS 2010: Large study of password deploymentsMozilla Firefox v 3.5.8 with:

Autofill Forms 0.9.5.2CipherFox 2.3.0Cookie Monster 0.98.0DOM Inspector 2.0.4Greasemonkey0.8.20100211.5Screengrab 0.96.2Tamper Data 11.0.1


WEIS 2010: Large study of password deploymentsfeature scoring

enrolmentPassword selection advice given +1 ptMinimum password length required +1 ptDictionary words prohibited +1 ptNumbers or symbols required +1 ptUser list protected from probing +1 ptCleartext password sent in email after enrolment −1 pt

loginPassword hashed in-browser before POST +1 ptLimits placed on password guessing +1 ptUser list protected from probing +1 ptFederated identity login accepted +1 pt

password updatePassword re-entry required to authorise update +1 ptNotification email sent after password reset +1 pt

password recoveryPassword update required after recovery +1 ptCleartext password sent in email upon request −1 ptUser list protected from probing +1 pt

encryptionFull TLS for all password submission +2 ptsPOST only TLS for password submission +1 pt


The realities of web authentication

0 100 200 300 400 500Traffic rank

0.0

0.2

0.4

0.6

0.8

1.0

Pro

por

tion

ofsi

tes

collec

tin

gp

assw

ord

s

Frequency of password collection


The realities of web authentication

∼ all websites collect email address as username∼ all websites use email for password reset∼ all websites use persistent login cookies by default


Many schoolbook errors are quite common

29-50% of sites store passwords in the clear



RockYou SQL injection hackJanuary 2010



countermeasure I E C Tot.

CAPTCHA 11 2 1 14timeout 2 1 2 5reset 1 3 1 5none 37 43 46 126

Many websites allow unlimited brute-force guessing



Ask

User probing is rarely prevented



interface I E C Tot.

enrolment 4 1 1 6login 43 41 38 132reset 11 7 2 20

all 1 1 0 2

User probing is rarely prevented



0.0 0.2 0.4 0.6 0.8 1.0success rate α

0

5

10

15

20

25

30

35

40m

argi

nal

gues

swor

kµ̃α

Password [RockYou]

Password [Klein]

Password [Spafford]

Password [Schneier]



TLS Deployment I E C Tot.

Full 10 39 10 59Full/POST 3 1 1 5Inconsistent 14 6 5 25None 23 4 34 61

TLS deployment remains uneven, poorly done



Firesheep


Security policies vary far more than requirements

0 1 2 3 4 5 6 7 8 9 10

No TLS, no password requirements, cleartext passwords emailed, no guessing or user probing restrictions, email addresses verified

No TLS, no password requirements or advice, emailed temp. passwords for reset, no password advice, no guessing or user probing restrictions, email addresses verified

TLS deployed, 6 char. min. password, emailed reset links, no password advice, no guessing or user probing restrictions, email addresses not verified

No TLS, 6 char. min. password, personal knowledge questions for reset, no password advice, no guessing or user probing restrictions, email addresses verified

TLS deployed, 6 char. min. password, emailed reset links, no password advice, guessing restrictions in place, email addresses verified

Sac. Bee

philly.com

Nashv. Scene

Victoria’s S. $

Macy’s $

eBooks

Huff. Post

USA Today

Ask Jeeves

TalkBizNow

EmailAccount Topeka C.-J.PhotoBucket $

Mail2WorldCanada.com

Mail.com StumbleUpon

Football Fan.

Indian Express

Fertility Fr.

CD Wow

Milwaukee J. S.

Florida-Times U.

The Pirate Bay

SoftHome

The Guardian

TCPalm

SF Chronicle

LiveMocha

Last.fm

The Drum

NY Times

Forbes

Truthdig

The Tennessean

The Courier-J.

PhillyBurbs

Lincoln J. S.

AOL Children’s Place $Xanga ESPN

Ticket Web $ TicketMaster $

Gap $ Barnes & Noble $ IMDB

Art Beads

Sus. Bus.

Seattle Weekly

New York Post

Ft. Worth S.-T.

Spiegel $

Shoplet

Blick

Weather Und.

Fin. Times $

Dallas M. N.

Reddit

CBS Sports

Bodybuilding $

3Dup

Two Peas in a B.

Weather Channel

Post-Tribune

Orlando Sent.

Miami.com

LA Times

Houston Chron.

Chicago Trib.

Wasabi

Sonico

hi5

Gawab

Rand McNally

Oriental Trad.

Hermes

Frederick’s $

Anthropologie $

The Economist

SJ Mercury News

CNN

CNET

Bill O’Reilly

ResearchGate

aNobii

Sierra T. P. $

Lucky Vitamin

efollet.com

Eddie Bauer

Costco $

A. & Fitch

Times Online

Press-Telegram

Bloomberg

Swiss Mail

Plaxo

Zappos! $

REI $

Overstock $

Home Depot $

DVD Empire $

Build-A-Bear W.

Best Buy $

Bath & Body W.

Reuters $

Walmart $

Things Rem.

Target $

ShopBop $

Sephora $

Sears $

NewEgg $

Horchow $

Amazon $

ZZ Network TigerDirect $ rediffTimes of India

On The Snow

Topix Ass. Cont. Twitter

W. S. JournalLinkedIn

DiggCraigslistDeviant Art $

Hushmail

Fairfax Dig.

Cafe Press $

MS Live

Wordpress Wash. Post

Yahoo!

Ebay $

Mixx Wikipedia

LiveJournal $

CNBC

Facebook $

Gamespot

AliBaba $

Google $

MySpace

IKEA

Godmail

JCPenney $

Buy.com $

The Golf World

Legend

Identity site

E-commerce site

Content site

Payment $

Cluster of sites

score


More popular sites do better

0

10

1E-2 1E-1 1E+0 1E+1 1E+2 1E+3 1E+4 1E+5

pas

swo

rd s

core

page views per million

E-commerce News/Customization User interaction


Economic failures

Bad websites can do real damage to good onesPassword insecurity is a negative externalityPassword over-collection is a tragedy of the commons


Looming authentication challenges

1 The old world2 The emerging world


OpenID—Single sign-onR Relying party (www.example.com)P OpenID Provider (Facebook, Google, etc.)

UE End user (a human)UA User agent (a browser)

UE −→ R I’m U@P!


OpenID—Single sign-on




UE −→ R I’m U@P!R ←→ P KR-P,n← D-H key exchange




UE −→ R I’m U@P!R ←→ P KR-P,n← D-H key exchangeUE ←− R OK, go verify with P (HTTP 302)UE −→ P I want to talk to R, who you share n with




UE −→ R I’m U@P!R ←→ P KR-P,n← D-H key exchangeUE ←− R OK, go verify with P (HTTP 302)UE −→ P I want to talk to R, who you share n withUE ←− P Sure you want to talk to R?



OpenID




UE −→ R I’m U@P!R ←→ P KR-P,n← D-H key exchangeUE ←− R OK, go verify with P (HTTP 302)UE −→ P I want to talk to R, who you share n withUE ←− P Sure you want to talk to R?UE −→ P Yes, here’s my password: p




UE −→ R I’m U@P!R ←→ P KR-P,n← D-H key exchangeUE ←− R OK, go verify with P (HTTP 302)UE −→ P I want to talk to R, who you share n withUE ←− P Sure you want to talk to R?UE −→ P Yes, here’s my password: pUE ←− P Okay, use MACKR-P(U,P) (HTTP 302)UE −→ R MACKR-P(U,P)! See, I’m U@P



Yahoo!




UE −→ R I’m U@P!R ←→ P KR-P,n← D-H key exchangeUA ←− R OK, go verify with P (HTTP 302)UA −→ P I want to talk to R, here’s my cookie cUA ←− P Okay, use MACKR-P(U,P)UA −→ R MACKR-P(U,P)! See, I’m U@P

(auth-immediate)


OAuth—Delegating API access

The Dark Ages



The Middle Ages

1 Facebook Connect2 Google AuthSub3 Yahoo BBAuth4 Twitter API: HTTP basic-authentication



1 App registration2 Access request3 User approval4 API Access



PLAINTEXT:M ||Kapp||Kuser

HMAC_SHA1:MACKapp||Kuser(M)

RSA_SHA1:SignKapp

(M)




Open issues

1 Standardisation2 Branding3 Security level4 Service discovery


Interaction via iframe


Preventing surrepititious authentication<img id="test" style="display:none">

<script>test = document.getElementById(’test’);var start = new Date();test.onerror = function(){ time = new Date() - start;}

test.src = "http://www.example.com/";</script>

Bortz et al. 2007


Preventing surrepititious authentication# Send users to my detector...<iframe name="detector"width="0" height="0" frameborder="0"src="https://docs.google.com/document/d/1TUV9x1lFAQcVWvhP4EAHQZIPrVmo3_vrz5Sz8Wo"></iframe>

Narayanan 2009


Preventing surrepititious authentication

Narayanan 2009


Workable backup authentication

Web searchReaching a head with OSNs

Public recordsGriffith et. al: 30% of individual’s mother’s maiden names

Social engineeringDumpster diving, burglaryAcquaintance attacks

Schecter et. al: ∼ 25% of questions guessed by friends, family



0.0 0.2 0.4 0.6 0.8 1.0success rate α

0

5

10

15

20

25

30

35

40m

argi

nal

gues

swor

kµ̃α Forename

Surname

Password [RockYou]

Password [Klein]

Password [Spafford]

Password [Schneier]

Personal knowledge worse than passwords (Bonneau et al. 2010)



Google—backup authentication by mobile phoneJ. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 9 / 10


Figure 2. Trustee-authentication email. This email contains a link thatidentifies the trustee to our website.

discourage trustees from responding to requests for account-recovery codes that arrive via email or text messages (theyare easy to spoof), we also discourage account holders fromcontacting their trustees using these channels.

We were not sure how many account-recovery codes shouldbe required to authenticate an account holder. We configuredthe system to require a threshold of three codes so that wecould measure the time required to obtain both the secondand third code. To obtain an account-recovery code, a trusteemust perform four steps.

InitiationWhen the trustee first visits the account recovery system, sheis asked to enter her email address and the address of theaccount holder she is assisting (Figure 1).

Trustee-authentication emailNext, the trustee receives an email from the account recoverysystem (Figure 2). If she is indeed a trustee for the specifiedaccount holder, the system creates a record to track the re-quest and the email sent to the trustee will contain a codepointing to this record. The trustee copies this link into herbrowser’s address bar to continue.

This emailed link and code are all that are required to provethe trustee’s identity and retrieve the account-recovery code.An attacker who could convince a trustee to forward theemail would be able to retrieve the code. Two countermea-sures against this attack are the email’s subject, which beginswith “**FOR YOU ONLY**”, and the message body, whichbegins with a conspicuous warning “do not forward any partof this email to anyone” (see Figure 2).

Figure 3. Query of intent. The trustee is asked to report why she isrequesting an account-recovery code.

Query of intentWhen the trustee pastes the link from the trustee-authenticationemail into her browser, she is asked to explain why she is re-questing an account-recovery code by choosing from a set ofoptions, illustrated in Figure 3. These options may conveythat she has heard from the account holder personally or thatshe is responding to a request from a third party.

The options that indicate the highest risk of fraud are listed atthe top in order to maximize the chance that the trustee willread them before making a choice. If the trustee chooseseither of the top two options, she encounters a warning pagethat describes telltale signs of fraud and encourages her tocontact the account holder by phone or in person. She is,however, given the option to disregard these warnings andcontinue.

PledgeFinally, the trustee is asked to pledge to her previous answerand to her understanding of the potential consequences ofgiving an account-recovery code to someone other than theaccount holder. This pledge requires her to type her name,as provided by the account holder, and to press a button thatsays “I promise the above pledge is true”. For example, ifa trustee reports receiving a request from the account holdervia voicemail, she would be asked to pledge that she willonly provide a code after she reaches him “in person”, asillustrated in Figure 4.

After the trustee has signed the pledge, the system presentsthe six character account-recovery code. If this is the firstaccount-recovery code requested for this account holder, thesystem will then email the remaining trustees to notify themof the event and encourage them to call the account holder.To further protect against attack, the account holder will benotified whenever he next logs in (or if he is already online).If an attack were underway, a call from his trustees wouldalert the account holder to login and halt the recovery pro-cess before the attacker can complete it.

Schecther et al. 2008

MS Live (proposed)—social backup authentication


Workable backup authenticationAlternative backup-authentication mechanismsThe ubiquity of mobile phones has made them an attractiveoption for backup authentication. Banks, such as by Aus-tralia’s CommonwealthBank [4], already send SMS mes-sages containing authorization codes to supplement primaryauthentication for high-risk transactions. However, authen-ticating users by their mobile phone alone is risky as phonesare frequently shared or lost—an estimated 60, 000 are losteach year in New York City cabs alone[5].

Some websites offer last-resort authentication through theircustomer-support departments. However, introducing hu-man customer support teams may not provide a strong ad-vantage over automated systems, as information used by sup-port staff to authenticate an account holder may be no bet-ter than the information available to the automated systems.For example, Google’s technical support form for passwordrecovery captures the IP address from which requests takeplace. Users are asked for their account creation date, lastlogin date, and the last passwords they remember [6]. Alas,last login dates have a tight distribution (most are recent) andonly the newest of users are likely to remember their accountcreation date. Microsoft’s form asks for the names of Hot-mail folders and contacts [8]. This information could be readover users’ shoulders. Furthermore, many users are unawarethis information is used for authentication and would thusnot know to withhold it should anyone ask.

Trustee-based authenticationThe concept of shifting the responsibility to authenticate anindividual from one party to another is not new. Authenticat-ing users via an alternate email address shifts the responsibil-ity to authenticate to the provider of that alternate address. Inorganizations, the responsibility to authenticate a user whofails primary authentication is often shifted to system admin-istrators, corporate security, or other support staff. Microsofthas long employed a form of trustee-based account recoveryfor its own employees: if an employee forgets her accountcredentials, her manager or coworkers can request a tempo-rary password on her behalf.

In 2006, Brainard et al. of RSA proposed a two-factor pri-mary authentication system (PIN and token) for enterpriseuse in which a user who lost her token could receive helpfrom a pre-selected trustee they called a “helper” [1]. Intheir system, the trustee authenticates using her two factorsin order to generate a “vouchcode” that substitutes for theaccount holder’s lost token. To our knowledge, no usabilityresults have been made available.

Whereas RSA’s system is designed for primary authentica-tion, ours is designed for last-resort authentication. We can-not assume that our users can contact a system administratorwhen all else fails. Whereas RSA’s system requires users toselect a helper (trustee) who has an account on the same sys-tem, ours requires only that trustees have email addresses.

Figure 1. Initiation. Trustees enter their email address and the addressof the account holder.

ACCOUNT RECOVERY VIA SOCIAL AUTHENTICATIONWe designed, built, and deployed an account recovery (pass-word reset) mechanism employing social authentication, inwhich users could authenticate by obtaining account-recoverycodes from three of four previously selected trustees. We de-ployed the system at recover.live.com where it wasmade to appear as a fully functional feature—though mem-bers of the public could not sign up to use the system fortheir own accounts.

The primary threat to a social authentication system is thatan attacker – someone other than the account holder – willconvince or trick the account holder’s trustees to vouch thatthe attacker is the account holder. That is, the attacker wouldrequest and receive the information required to obtain anaccount-recovery code. The attacker might do this by im-personating the victim or by convincing the trustee that heor she is acting on behalf of the victim.

In this section we provide an overview of the system, userexperience, and countermeasures to defend against attacks.

ConfigurationOur social authentication mechanism required that users pro-vide the names and email addresses of four trustees in ad-vance of use. We did not test the configuration step as partof this study. We also chose not to inform trustees of their se-lection: we feared this might lead them to ask account hold-ers about the system, learn it was a prototype, and therebychange their security behavior.

RecoveryWhen an account holder needs to recover his1 account, hemust obtain account-recovery codes from his trustees. Ac-count holders instruct their trustees to visit the account-recoverysystem at recover.live.com. We encourage accountholders to call or visit their trustees in person. Because we1For clarity, we use masculine pronouns for the account holder andfeminine pronouns for trustees.

Schecther et al. 2008

MS Live (proposed)—social backup authentication



Facebook—social questions backup


Questions

[email protected]


joseph bonneau - cl.cam.ac.uk€¦ · no tls, 6 char. min. password, personal knowledge questions...

Documents