1 Convenient Decentralized Authentication using PasswordsTim van der Horst Internet Security Research Lab Brigham Young University Aim for 35 minute presentation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Passwords are a very convenient way to authenticate. In terms of simplicity and portability: they are very difficult to match. But… they are not without their problems. Simple slide about passwords, then move to Bob People have too many passwords they are not currently being used in a scalable fashion. they do not scale well. Good morning. Over the past several years I’ve been trying to make it possible for people to conveniently and securely leverage their accounts to log in to web sites and wireless networks. A big motivator for me is to reduce the number of passwords that people have. Dissertation Defense November 6th, 2009 Provo, Utah
2 Passwords Username: Password: Bob p455w0rd LoginNow which password did I use for Borders… Username: Password: Bob p455w0rd Login Where’s that “Forgot my password link” … 5.5” circle for pictures
3 Decentralized AuthenticationWho do we trust? Providers Password 5.5” circle for pictures
4 Simple Authentication for the WebHow can web sites offload user authentication all by themselves? Already doing it as a secondary means of user authentication SAW’s approach Improve the security and convenience of - based password resets Use as primary authentication mechanism Our first step to leverage this emergent trust, …, was to see what can be done right now to enable web sites to authenticate people based on their accounts. //As I mentioned, web sites already use to resets passwords. The goal of SAW is to improve the security and convenience of ebpr and move them from the background into the forefront. And replace the account password. [First 3 slides take about 2 minutes] ~~~~~~~~~ Web sites have already taken the first step. They use to reset passwords.
5 How SAW Works Step 1: Step 2: Step 3:User Web Site I’m Alice Step 1: The user submits her address Step 2: If her address is authorized, a random secret is generated and split into two shares Step 3: The user returns both tokens Manually: By clicking a link in the Automatically: Using the SAW toolbar Tokens are: Short-lived Single-use To login using SAW, a user first submits her address… ---- General Notes --- One token is useless without the other, IDP never (passively) gets both tokens From: To: Subject: [SAW-https://securecomm.org/login] AT =2fe32... Click on the link below ONLY if you recently initiated a request to log in to https://securecomm.org/login: https://securecomm.org/login?AT =2fe eb5dea... User’s Provider
6 Benefits Unilateral deployment by web sitesNo specialized third party No client-side software Reuse existing users identifiers and authenticators external to the web site Acceptable risks for services that relies on - based password resets Advanced features Delegation and revocation through forwarding rules Client-side auditing Authenticators in this case a fancy way of saying passwords, but it could be other forms of authentication.
7 Sharing and Collaborationaddresses are cross-domain, unique identifiers Use SAW to allow users to prove ownership of their identifiers --- General Notes --- One of the strengths of SAW is easy account provisioning. addresses are one of, if not the most, pervasive globally unique identifiers that there are. To get a feel on those outside of our lab would To get a feel on the usability of SAW, we deployed it to the class blog for BYU’s computer security course. Account provisioning.
8 Drawbacks of SAW Convenience SecurityDependent on the latency of Instant messaging is an attractive alternative Security Vulnerable to a one-session, active impersonation attack --- General Notes --- SAW is a very simple idea. How can we expand it? -> Motivate wireless application using site visit example In SAW, users must directly communicate with their provider Chicken and egg problem for wireless networks
9 Active Impersonation AttackAttacker Web Site I’m Alice Step 1: Attacker submits the victim’s address Step 2: Server actions remain the same Attacker eavesdrops the ed token Step 3: Attack submits both token to log in as the victim Sites that employ EBPR are also susceptible to a similar attack Prolific adoption of EBPR indicates that this is an acceptable risk Manageable Risk Also, turning on encrypted tunnels between providers solves this except for the case of malicious insiders. The hybrid approach can be used to increase the difficultly of an active impersonation attack Victim’s Provider
10 Wireless Authentication using Remote Passwords (WARP)How can the principles behind SAW be leveraged for wireless network authentication? How can this approach be improved with the participation of the provider? --- Be sure to practice this transition The convenience of using address to specify who can get access to a resource is very appealing. The next protocol I would like to show you is called WARP. It represents our efforts to adapt the principles of a SAW authentication to wireless network authentication. The idea is that you can control who can gain access to a wireless network though a list of approved addresses. Rather than creating usernames and passwords or having a shared passphrase that everyone uses. We also wanted to examine how things can be improved by the active participation of the provider in the authentication process. Recall that in SAW we used completely unmodified providers. ~~~~~~~~~~~~~~~~~ Wouldn’t it be great if a simple process could be used to provision access to a private wireless network. Our next area, WARP, adapts SAW for wireless network authentication. We dropped the requirement for unmodified identity providers in order to examine what benefits are possible with their active involvement.
11 The Chicken and the Egg How do users authenticate to identityproviders when they cannot directly communicate? Giving relying parties the plaintext password is not desirable Allowing an encrypted tunnel invites misuse and requires IP-level connectivity Forwarding several small messages of known composition offers a good compromise Don’t talk about mint.com? User (U) Wireless Access Point (RP) Identity Provider (IDP) Msg ID: Alice PW: Peek-a-boo
12 Secure Remote Password (SRP)WARP – High Level Idea User (U) Wireless Access Point (RP) Identity Provider (IDP) Secure Remote Password (SRP) Use SRP to establish a mutually authenticated session key between user and her identity provider Use that key to facilitate a SAW token distribution --- General Notes --- SRP is designed to be used over insecure channels
13 WARP User Access Point Identity Provider I I g, N, s, B g, N, s, B(authorize I) I (lookup s, v, g, N) B = kv + gb g, N, s, B g, N, s, B A = ga K = (B - kgx)a+ux (compute PU) A, PU KS = KSIDP KSU K = (Avu)b (verify PU) (compute PIDP) A, PU KSIDP E(K, KSIDP), KSU PIDP E(K, KSIDP) (encrypt KSIDP) PIDP (verify PIDP) PKS (decrypt KSIDP) KS = KSIDP KSU (compute PKS) (verify PKS)
14 Threat Analysis Both channels Passive observation of KSg, N, s, B g, N, s, B Both channels Passive observation of KS Use encrypted tunnel One-session, active impersonation attack SAW is vulnerable to a similar attack Attacker initiates the protocol to learn KSU Eavesdrops KSIDP Counter by encrypting KSIDP Still valuable without this protection A, PU A, PU KSIDP E(K, KSIDP), KSU E(K, KSIDP) PIDP PIDP PKS Encrypted Tunnel (e.g., EAP-TTLS) I Dreq --- General Notes --- Replaced returning the tokens with a proof of token ownership g, N, s, B D A, PU KSIDP E(D, KSIDP) PIDP E(K, KSIDP)
15 Areas to Improve in WARPPassive protection without requiring PKI Protect sessions with unauthenticated hosts from passive eavesdropping Easier integration with existing systems Leverage existing password verifier databases --- General Notes --- Without PKI includes RP and IDP Having a key as an end product is not that useful in web scenarios Our most recent system, Luau, addresses these issues. Before I discuss Luau, I want to examine a system called pwdArmor. It started as a simple wrapper to facilitate the use of existing databases of password verifiers, but grew into a generic middleware framework that augment the assurances of conventional password protocols.
16 The tunnel also authenticates the hostpwdArmor: The Problem Password logins often need an encrypted tunnel to prevent exposure of the user’s password HTML login pages SSH “keyboard-interactive” Encrypted tunnels can be circumvented Username: Password: Bob p455w0rd Login The tunnel also authenticates the host The problem is
17 Circumventing Encrypted TunnelsAssume user is talking to the attacker Do not create it Hope the user doesn’t notice Certificate trick Valid certificate for the attacker Or assume user ignores browser warnings 99.23% of Phishing occurs over plain HTTP* The crux of the problem is that it is the sole responsibility of the user to ensure that the tunnel is: Created Established with the correct host Let’s assume that the user is communicating with the attacker and is under the impression that he is talking to the correct host The most common approach to circumvent the tunnel is to simply not create it and hope that the user does not notice. Notes: The root cause of these shortcomings is that: It is the sole responsibility of the user to make sure that this is right. Two problems, either gets the password, or it can pass through the “digest” and log in as the user. Username: Bob Password: p455w0rd Encrypted Tunnel (e.g., TLS) * Anti-Phishing Working Group, January 2008
18 Encrypted tunnels can be circumventedGoals for pwdArmor Prevent exposure of the plaintext password Even without the encrypted tunnel Mitigate damage when authenticating to the wrong host Limit effectiveness of password phishing Reuse existing password protocols and verifier databases Maintain compatibility with legacy systems Encrypted tunnels can be circumvented --- General Notes --- Even without the encrypted tunnel Improve detection of MITM attacks Add bilateral detection
19 Target Deployment ScenariosSclear Unencrypted channel for communications E.g., HTTP Stunnel Encrypted channel for communications E.g., HTTPS, SSH Don’t want to use the tunnel as a crutch Use tunnel for: Improved identification of the host Secure the resulting session
20 pwdArmor: High Level ApproachEncrypt user’s authentication response Key based on two parts: The result of a Diffie-Hellman (DH) key exchange An attacker must compromise DH exchange The user’s password verifier An attacker must compromise the legitimate host Bind the password protocol to the tunnel Compound authentication binding problem Something only the other party should know Something only the real server should know --- General Notes --- If just 1, then active attacker gets the password If just 2, then everyone get material for an offline attack, With both, the password is always protected because the attacker won’t have both components. If DH mitm is used at we leak material for offline guessing Add an authenticated message from Host to inform of mitm IDH Allow the host to detect man-in-the-middle attacks IDH
21 Deployment ConsiderationClient-side support is required to use pwdArmor Significant deployment hurdle Web browsers are nice test-bed for incremental deployment Browser extensions, zero-footprint clients (e.g., Java Applets) The user’s password must be given to the client-side software Not a problem for many situations SSH client, wireless supplicants, etc. Significant problem for web browsers Most logins use a server-supplied HTML login page Entering passwords via the browser’s chrome is an attractive alternative Provides a consistent login experience across all domains Increased willingness by major players to provide client-side support (e.g., CardSpace, Higgins) Web browsers already have rudimentary support for this to enable HTTP Basic and Digest authentications
22 Luau: Lightweight User AUthenticationBrings together the lessons learned from SAW, WARP, and pwdArmor Passive protection without PKI Decoupled from SRP More web friendly Lends itself well to study in existing proof models --- General Notes --- Returning to decentralized authentication, Luau brings… More web friendly: Don’t just create a key, use TLS for server-auth and for encrypted session and bind them together. Proof models: BR93, BR95, BPR00, CK01
23 Luau Building Blocks Pre-authentication phaseEstablish key between user and IDP a priori In-band: Service provider relays messages Out-of-band: Directly with identity provider nU nRP EKU,IDP(KU,RP) MACKU,IDP(, EKU,IDP(KU,RP)) EKRP,IDP(KU,RP) MACKRP,IDP(, EKRP,IDP(KU,RP)) = IDU, IDRP , nU, nRP 3 Party Key Distribution (3PKD)* nU MACKU,RP(IDU, IDRP , nRP , nU) MACKU,RP(IDRP , nU) nRP Mutual Authentication Protocol 1 (MAP1)† --- General Notes --- These building blocks are well studied pwdArmor would be used in the pre-authentication phase, particularly helpful with in-band nIDP nRP gx gy Diffie-Hellman Key Exchange *(3PKD): Bellare and Rogaway, 1995 †(MAP1): Bellare and Rogaway, 1993
24 Complicated by unauthenticated service providersConstructing Luau 3PKD cannot be utilized “as-is” Service provider and identity provider do not share a key Solution Replace the key distribution portion between service provider and identity provider with DH Scalability: Every website and every provider are NOT going to establish a key Complicated by unauthenticated service providers Service provider can no longer use the key from 3PKD to authenticate to the user
25 3PKD (key distribution & integrity)Luau: High Level DH (key exchange) 3PKD (integrity) Out-of-band more feasible in web scenarios, also simplifies the analysis of the protocol MAP1, needs shared symmetric key Don’t have one, how can we get it 3 party key distribution Both parties require keys with the TTP Only feasible for one of them, how can the other get it? Diffie-Hellman key exchange Use TLS to authenticate IDP if necessary Show backwards Then show how a reduction proof could follow a similar approach Reduce to DH key exchange, an strength of pre-auth phase 3PKD (key distribution & integrity) MAP1
26 MACKU,RP(IDU, IDRP , nRP , nU)Luau: Protocol Encrypted Tunnel (e.g., TLS) nU IDU gx nU nRP IDU nRP EKU,IDP(KU,RP) MACKU,IDP() gy nIDP MACKRP,IDP() EKU,IDP(KU,RP) MACKU,IDP() MACKU,RP(IDU, IDRP , nRP , nU) MACKU,RP(IDRP , nU) Lessons integrated from pwdArmor Bind to TLS tunnel Only between User and RP, not RP and IDP (explain) Not as strong because = IDU, nU, nRP , EKU,IDP(KU,RP) = , MACKU,IDP(), nIDP , gx, gy Encrypted Tunnel (e.g., TLS) kU,IDP = [from pre-auth phase] kRP,IDP = PRFr(gxy); r = nRP || nIDP kU,RP = PRFKRP,IDP (“key”)
27 Luau: Threat Analysis OutlineReduce to pre-auth and DH key exchange Reduce DH (key exchange) Out-of-band more feasible in web scenarios, also simplifies the analysis of the protocol MAP1, needs shared symmetric key Don’t have one, how can we get it 3 party key distribution Both parties require keys with the TTP Only feasible for one of them, how can the other get it? Diffie-Hellman key exchange Use TLS to authenticate IDP if necessary Show backwards Then show how a reduction proof could follow a similar approach Reduce to DH key exchange, an strength of pre-auth phase 3PKD (integrity) 3PKD (key distribution & integrity) MAP1
28 Summary: Lessons LearnedAn authentication protocol is simply a container for “trust” Can transport it Can potentially reinforce it Cannot create it providers are the de facto trusted third parties on the Internet Situated to become even more valuable Represent a practical reuse of existing trust There’s a lot of good authentication protocols Adoption is the tricky part Trust is the big sticking point for decentralized authentication Lessons Learned It’s not so much that new technology is needed. There’s lots of great stuff. Adoption is the tricky part, trust is a big sticking point. Global changes are difficult There is the potential that things will never change. One of the biggest contributions of this work is the argument that providers, and personal messaging providers, are the de facto identity providers on the Internet. They have the potential to become even more valuable in this respect. EBIA has demonstrated this. Even when the providers are unauthenticated. Practical reuse of existing relationships Security is typically imposed upon people. Important observation. The technology is only a container of the trust. The technology can help transport it, potentially reinforce it, but it cannot create it where there is no trust to begin with. Authentication technology is only a container/transporter of trust. excellently situated to become There are no guarantees that the best technology will win. The factors seem to be “good enough” and positioned at the right place at the right time.
29 What else can we learn? Premature to move away from passwordsI’m not dead yet … What else can we learn? RIP Passwords Premature to move away from passwords Simple, convenient, and portable Password-based decentralized authentication is a bridge 1:1 to 1:n animation Decentralized authentication Extend their useful lifetime Use them as a bridge to stronger technologies --- General Notes --- Use passwords to bootstrap decentralized authentication --- Suggestions on additional slides - A vision/opinion/ why this important - contributions/ future work - adoption problems - What I have begun that other can build on - --- Brainstorm --- - Derivative applications slide - “Big Picture Slide” Biometrics Password Smart Cards Easier to require strong forms of authentication when it has to be used in fewer places Stronger motivation to do so as more things depend on it
30 Where do we go from here? Land of Direct AuthenticationLand of Decentralized Authentication Gulf of Execution Passwords WARP PINs Prove “what” you are not “who” you are Luau SAW I didn’t invent decentralized authentication. Why attributes are cool. Add other technologies from related work Kerberos (active directory) (client certs, openID, role-based access control) Microcosms of decentralized authentication. Single sign-on (businesses have small systems, we’ll looking at doing it for the masses) Work was two-fold: understanding the problem; designing the protocol. Applied design. Threat analysis vs. formal proof Who do you trust? Legal/Business Agreements Secret questions/answers pwdArmor Attribute mountains Digital certificates OpenID Liberty/Shibboleth/CAS Kerberos Password Managers (online/offline)
31
32 Related Work Password Managers (online/local)PKI-based approaches (a.k.a. client- certificates) OpenID (URL-based authentication) Other password-based decentralized solutions Liberty/Shibboleth/CAS CardSpace/Higgins
33 Legal/Business aggreementsLand of Direct Authentication Land of Decentralized Authentication What Vs. Who Secret questions/answers Legal/Business aggreements SAW ( providers) Passwords Gulf of Execution Something else Gloomy in the land of direct authentication Smilely faces in the land of decentralized authentication Passwords, pins, and secret questions/answers PINs Luau Attribute mountains pwdArmor WARP Who can you trust?
34 Authenticate based on “what” you are vs. “who” you areWhere do we go from here? Grassroots No one has attribute certificates No one issues attribute certificates Major player(s) pwdArmor Where did we come from? Need trusted attribute providers Trust Negotiation Authenticate based on “what” you are vs. “who” you are What can be done right now? An address is an attribute Universities know about its students Employers about employees Financial Institutions know about payments Certificates are just a container SAW Need trusted attribute providers Need trusted third parties Are you a student? Can you pay for it? Do you have a driver’s license? Are you old enough? Move away from who you are and shift to what you are (nice for privacy) WARP/Luau Something Else
35 Where do we go from here? Where did we come from?Certificates are just a container No one has attribute certificates No one issues attribute certificates Need trusted attribute providers Trust Negotiation What can be done now SAW pwdArmor Grassroots Major player(s) WARP/Luau An address is an attribute Universities know about its students Employers about employees Financial Institutions know about payments What the future could look like Move away from who you are and shift to what you are (nice for privacy)
36 Where to go from here? Past Master’s theses Patents Adoption problems5 master’s theses based on this work EPAK, WARP, CPG, EAS , KiwiVault One proposed Patents SAW Trusted Overlays Adoption problems SAW has unilateral adoption model Luau requires global changes Trust negotiation -> SAW -> Warp -> Luau -> Trust negotiation Technical foundations are there, it’s a matter of adoption There are steps in the right direction
37 Hidden Content Follows (including this Slide)Additional Content Hidden Content Follows (including this Slide) Add if presentation time permits
38 pwdArmor Framework E( ) MAC( ) IDH DH Key Exchange IDU nU gx nH [C]Key Derivations KU,H PRFr(gxy); r = nU||nH Encryption Key PRFKU,H(verifier, “enc”) MAC Key PRFKU,H(verifier, “mac”) DH IDH DH Key Exchange DH IDU nU Use IDU to lookup the correct verifier and may be necessary for [C] DH contains the info necessary to derive the verifier from the password Last message is not sent if gx nH [C] DH gy E( ) IDU RU IDH IDU ensures that the host got the correct IDU Verifier is used to help compute the Encryption and MAC keys MAC( ) [RH] IDU IDH IDH used to help detect man-in-the-middle attacks Encrypted Tunnel
39 Conventional Password ProtocolsAnalysis Summary Conventional Password Protocols pwdArmor Tunnel No Tunnel Bad Tunnel Type-0/1 Eve None Mallory LEAK, MITM* Type-0 Type-1 Type-2 Eve PWD, LEAK LEAK None Mallory PWD, LEAK, MITM LEAK, MITM * Only for routing-MITM Type-0/1 Eve None Mallory LEAK
40 Additional SAW ContentMotivation Alternative to Threats Animated description of one-session, active impersonation attack
41 Motivation People have too many passwords Difficult to securely shareEncourages password reuse Leads to forgotten passwords Burdens users and administrators Difficult to securely share Leads to public sharing Or no sharing at all Password phishing Users are tricked into giving away their passwords (wireless access, photos, files)
42 Alternatives to Email & AutomationSAW can leverage other personal messaging mediums Instant messaging Text messaging Paging messaging Hybrid (e.g., + IM) Automation SAW toolbar
43 Threats Passive Eavesdropping Password Phishing Compromised ServerAn attacker must obtain both tokens AND submit them before the user If HTTPS is used on the login page the token sent directly to the user cannot be passively observed Password Phishing The only user information disclosed in a login is their address SAW does not prevent users from divulging other sensitive information to a phishing site Compromised Server No user passwords to steal
44 Additional WARP ContentAlternative solutions to the chicken and egg problem of online decentralized authentication Also has motivation of our approach
45 Additional pwdArmor ContentOriginal (two slides) animated motivation from ACSAC presentation Target deployment scenarios Motivate decision to operate without TLS And what we will rely on TLS for when used High level approach of pwdArmor Motivate inclusion of IDH in message #3 pwdArmor protocol Deployment considerations Motivate the need to move authentications outside of web pages and into a trusted interface The ACSAC slides have the following available if more time is to be devoted to pwdArmor Encapsulating conventional password protocols 9 slides of Security analysis
46 Implementation: 3 ExamplesHTTP Basic MD5-based BSD verifiers OTP HTTP Digest verifiers DH IDU nU DH gx nH [C] DH gy E( ) IDU RU IDH Thwarts the “small n” attack MAC( ) [RH] IDU IDH (digest verifiers) If only used for this we can convert existing password db into password-dependent OTP w/ SHA1 alg=otp-sha1, seed=pongo, cnt=100 C Otp-sha1 99 pongo RU AND FULL FAN GAFF BURT HOLM Basic w/ Digest alg=http-digest, realm=Hoth RU password Basic w/ BSD alg=apr1, salt=CGyXh… RU password Verifiers were originally stored in a dependent way but used in an equivalent fashion
47 Emergent Trust in Email ProvidersCould use pwdManager with credentials stored in the Cloud (prevSlide) The passwords are still there Account-specific managament Two valuable lessons from ebpr Simplicity I believe that ebpr has taught us something valuable Pwds are not necessary only a convenience, proving ownership of is the valuable part. -based password resets 2 Points: Unilateral deployment Emergent trust in EP (more valuable in the long run. Who do we trust, and for what? Big issue with client-side PKI?
48 Guidelines Audience: CS faculty and CS graduate students.Do not assume that either the faculty or the graduate students are knowledgeable in your specialty research area. The presentation should be similar to one that would be made in a graduate colloquium.
49 Outline
50 The Defense The defense is open to the public. Consists ofA minute presentation of the candidate's research Questions from the audience. After public portion, everyone leaves but the committee. The committee makes a preliminary assessment and decides on further questions, if any, the candidate returns to answer the questions of the committee. Candidate is excused and committee votes.
51 Already a trusted third partyWhat else can we learn? Premature to move away from passwords Simple, convenient, and portable Extend their useful lifetime through decentralized authentication providers are a good place to start Web site logins are ripe for change Major players are working on changes Future work Attribute-based authentication Already a trusted third party --- General Notes --- Use passwords to bootstrap decentralized authentication --- Suggestions on additional slides - A vision/opinion/ why this important - contributions/ future work - adoption problems - What I have begun that other can build on - --- Brainstorm --- - Derivative applications slide - “Big Picture Slide”
52 Decentralized AuthenticationBob’s in-memory password lookup table password1 ??? Luke Password2 Ducky Password3 photos Zxcv letmein pwd12 qwer Lkjh asdf Use Bob to motivate the need for decentralized authentication and to define what that means. ~~~~~~~~~~~~~ Take Bob, for example. Bob uses a variety of online services. Each of these services requires a password. As you can see Bob does his best to remember these passwords, but his memory is a little patchy. Doesn’t remember what his Border’s or best buy passwords are, but he thinks he used the same one for both. I believe that Bob shouldn’t have to remember so many passwords. If these web sites supported an indirect, or decentralized, approach to authentication, then Bob wouldn’t have to even bother with account-specific passwords. He could rely on a trusted third party to vouch for him. In order to make such a system work, users and web sites must agree on who to trust; lack of agreement here is a deal-breaker. I believe that they have already made a viable choice: Providers. A large number of web sites rely on to reset the account-specific password, if it is lost or forgotten. The goal of my research over the past couple of years has been to reduce the need for account-specific passwords. create secure and convenient approach to An important question to ask when creating this type of system is who do we trust as this third party? To preserve the convenience of passwords, Bob could use a password to authenticate to this third party. Maintain much of the convenience and portability of passwords, but would have fewer. The observation that got me started on my disertation Reduce the need for service-specific passwords, I believe that we’ve found and intuitive way to do it. He likes to frequent a variety of sites online and has accounts at many of them. Let’s take a look inside Bob’s head. As you can see, Bob remembers that he has accounts at various sites, but he has trouble remembering some of his passwords. And with the help of my friend Bob here I’ll tell you why. The Internet is filled with a variety of useful sites and services. PwdManagers simply hind the fact that the passwords are not there. But why? I’m going to use bob here as an example. There is a lot a fun stuff to do on the Internet. But for Bob to participate and he needs to create accounts: That means passwords. Bob has opted for the in-memory look-up table approach to password management. As you can see he has a number of gaps in his table. The grease that keeps everything going is EBPR. ~~~~ Ebay, amazon, Flickr, Google, Live, Yahoo!, AOL, blogspot, facebook, myspace, twitter, digg, slashdot, ars, buy, nsf, Costco, BestBuy, Barnes Noble, Borders, Who do we trust? The Internet Password
53 Passwords Username: Password: Bob p455w0rd
54 Passwords Username: Password: Bob p455w0rd
55
56 Decentralized AuthenticationBob’s in-memory password lookup table password1 ??? Luke Password2 Ducky Password3 photos Zxcv letmein pwd12 qwer Lkjh asdf Use Bob to motivate the need for decentralized authentication and to define what that means. ~~~~~~~~~~~~~ Take Bob, for example. Bob uses a variety of online services. Each of these services requires a password. As you can see Bob does his best to remember these passwords, but his memory is a little patchy. Doesn’t remember what his Border’s or best buy passwords are, but he thinks he used the same one for both. I believe that Bob shouldn’t have to remember so many passwords. If these web sites supported an indirect, or decentralized, approach to authentication, then Bob wouldn’t have to even bother with account-specific passwords. He could rely on a trusted third party to vouch for him. In order to make such a system work, users and web sites must agree on who to trust; lack of agreement here is a deal-breaker. I believe that they have already made a viable choice: Providers. A large number of web sites rely on to reset the account-specific password, if it is lost or forgotten. The goal of my research over the past couple of years has been to reduce the need for account-specific passwords. create secure and convenient approach to An important question to ask when creating this type of system is who do we trust as this third party? To preserve the convenience of passwords, Bob could use a password to authenticate to this third party. Maintain much of the convenience and portability of passwords, but would have fewer. The observation that got me started on my disertation Reduce the need for service-specific passwords, I believe that we’ve found and intuitive way to do it. He likes to frequent a variety of sites online and has accounts at many of them. Let’s take a look inside Bob’s head. As you can see, Bob remembers that he has accounts at various sites, but he has trouble remembering some of his passwords. And with the help of my friend Bob here I’ll tell you why. The Internet is filled with a variety of useful sites and services. PwdManagers simply hind the fact that the passwords are not there. But why? I’m going to use bob here as an example. There is a lot a fun stuff to do on the Internet. But for Bob to participate and he needs to create accounts: That means passwords. Bob has opted for the in-memory look-up table approach to password management. As you can see he has a number of gaps in his table. The grease that keeps everything going is EBPR. ~~~~ Ebay, amazon, Flickr, Google, Live, Yahoo!, AOL, blogspot, facebook, myspace, twitter, digg, slashdot, ars, buy, nsf, Costco, BestBuy, Barnes Noble, Borders, Who do we trust? The Internet Password
57 What else can we learn? Premature to move away from passwordsI’m not dead yet … What else can we learn? RIP Passwords Premature to move away from passwords Simple, convenient, and portable Password-based decentralized authentication is a bridge Passwords Biometrics Smart Cards 1:1 to 1:n animation Decentralized authentication Extend their useful lifetime Use them as a bridge to stronger technologies --- General Notes --- Use passwords to bootstrap decentralized authentication --- Suggestions on additional slides - A vision/opinion/ why this important - contributions/ future work - adoption problems - What I have begun that other can build on - --- Brainstorm --- - Derivative applications slide - “Big Picture Slide” Easier to require strong forms of authentication when it has to be used in fewer places Stronger motivation to do so as more things depend on it