Post on 02-Aug-2020
User authentication on the web
Joseph Bonneaujcb82@cl.cam.ac.uk
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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 1 / 10
WEIS 2010: Large study of password deployments
“Identity” websites
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 2 / 10
WEIS 2010: Large study of password deployments
“E-Commerce” websites
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 2 / 10
WEIS 2010: Large study of password deployments
“Content” websites
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 2 / 10
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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 2 / 10
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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 2 / 10
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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 2 / 10
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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 3 / 10
Many schoolbook errors are quite common
29-50% of sites store passwords in the clear
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 4 / 10
Many schoolbook errors are quite common
RockYou SQL injection hackJanuary 2010
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 4 / 10
Many schoolbook errors are quite common
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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 4 / 10
Many schoolbook errors are quite common
Ask
User probing is rarely prevented
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 4 / 10
Many schoolbook errors are quite common
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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 4 / 10
Many schoolbook errors are quite common
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]
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 4 / 10
Many schoolbook errors are quite common
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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 4 / 10
Many schoolbook errors are quite common
Firesheep
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 4 / 10
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.
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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 5 / 10
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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 6 / 10
Economic failures
Bad websites can do real damage to good onesPassword insecurity is a negative externalityPassword over-collection is a tragedy of the commons
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 7 / 10
Economic failures
Bad websites can do real damage to good onesPassword insecurity is a negative externalityPassword over-collection is a tragedy of the commons
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 7 / 10
Economic failures
Bad websites can do real damage to good onesPassword insecurity is a negative externalityPassword over-collection is a tragedy of the commons
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 7 / 10
Looming authentication challenges
1 The old world2 The emerging world
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 7 / 10
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!
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 8 / 10
OpenID—Single sign-on
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 8 / 10
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!R ←→ P KR-P,n← D-H key exchange
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 8 / 10
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!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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 8 / 10
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!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?
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 8 / 10
OpenID—Single sign-on
OpenID
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 8 / 10
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!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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 8 / 10
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!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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 8 / 10
OpenID—Single sign-on
Yahoo!
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 8 / 10
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!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)
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 8 / 10
OAuth—Delegating API access
The Dark Ages
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 9 / 10
OAuth—Delegating API access
The Middle Ages
1 Facebook Connect2 Google AuthSub3 Yahoo BBAuth4 Twitter API: HTTP basic-authentication
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 9 / 10
OAuth—Delegating API access
1 App registration2 Access request3 User approval4 API Access
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 9 / 10
OAuth—Delegating API access
1 App registration2 Access request3 User approval4 API Access
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 8 / 10
OAuth—Delegating API access
1 App registration2 Access request3 User approval4 API Access
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 7 / 10
OAuth—Delegating API access
PLAINTEXT:M ||Kapp||Kuser
HMAC_SHA1:MACKapp||Kuser(M)
RSA_SHA1:SignKapp
(M)
1 App registration2 Access request3 User approval4 API Access
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 6 / 10
OAuth—Delegating API access
Open issues
1 Standardisation2 Branding3 Security level4 Service discovery
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 6 / 10
Interaction via iframe
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 7 / 10
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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 8 / 10
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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 8 / 10
Preventing surrepititious authentication
Narayanan 2009
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 8 / 10
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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 9 / 10
Workable backup authentication
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)
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 9 / 10
Workable backup authentication
Google—backup authentication by mobile phoneJ. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 9 / 10
Workable backup authentication
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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 9 / 10
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
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 9 / 10
Workable backup authentication
Facebook—social questions backup
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 9 / 10
Workable backup authentication
Facebook—social questions backup
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 9 / 10
Questions
jcb82@cl.cam.ac.uk
J. Bonneau (U. of Cambridge) SOCIALNETS November 18, 2010 10 / 10