Simple Authentication for the Web Tim van der Horst and Kent Seamons Internet Security Research Lab Brigham Young University SecureComm 2007 (Nice, France) ISRL Internet Security Research Lab http://isrl.cs.byu.edu

Introduction Users have too many passwords Potential Alternatives Encourages password reuse Leads to forgotten passwords Burdens users and administrators Potential Alternatives Password managers Generally lack portability Account-specific management Indirect Authentication Increased overhead and complexity Specialized identity provider PKI-based solutions, Liberty, Shibboleth, OpenID, etc.

Goals Make authentication more convenient, while at least maintaining the current level of security Remove the need for site specific passwords Simple for users to understand and use Easy for administrators to deploy and manage

Background Email-Based Password Reestablishment (EBPR) SAW’s Approach Many sites use email to reset passwords Secondary means to authenticate users Efficient and cost-effective Risks are manageable SAW’s Approach Remove site-specific passwords Improve the security and convenience of EBPR

How SAW Works Step 1: Step 2: Step 3: User Web Site I’m Alice Step 1: The user submits her email 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 email Automatically: Using the SAW toolbar Tokens are: Short-lived Single-use From: SAW_TokenGenerator@securecomm.org To: student@some.edu Subject: [SAW-https://securecomm.org/login] ATemail=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?ATemail=2fe322492847eb5dea... User’s Email Provider

Alternatives to Email & Automation SAW can leverage other personal messaging mediums Instant messaging Text messaging Paging messaging Hybrid (e.g., email + IM) Automation SAW toolbar The original token can be split into n tokens Require m of n tokens to be returned Time to check for messages Total login time using email Total login time using IM Gmail Account 2.5s 4s <1s Private Account 1s 1.5s n/a

Threats Passive Eavesdropping Password Phishing Compromised Server An 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 email address SAW does not prevent users from divulging other sensitive information to a phishing site Compromised Server No user passwords to steal

Active Impersonation Attack Attacker Web Site I’m Alice Step 1: Attacker submits the victim’s email address Step 2: Server actions remain the same Attacker eavesdrops the emailed 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 The hybrid approach can be used to increase the difficultly of an active impersonation attack Victim’s Email Provider

Advanced Features Sharing and Collaboration Client-based Delegation Client-side auditing

Sharing and Collaboration Specify the users that can have access Email addresses are cross-domain, unique identifiers Use SAW to allow users to prove ownership of their identifiers //Sample .htaccess file AuthBasic AuthType Basic AuthName “PrivateRealm” AuthUserFile c:\basic Require user timv respectablebusinessman seamons //Sample .htaccess file AuthSAW AuthType EBAC AuthName “PrivateRealm” Require user timv@cs.byu.edu 801-422-7893 kentseamons@gmail.com

Client-Based Delegation Allow clients to delegate access (authorized impersonation) Without sharing passwords Without modifying the service provider Accomplished through email forwarding rules Provides an up-to-date list of delegations Facilitates revocation

Client-Based Delegation Example Bob delegates access to Alice Step 1: Alice submits Bob’s email address Step 2: Server actions remain the same Bob’s email provider forwards the token to Alice Step 3: Alice submits both tokens Web Site X I’m Bob Forward tokens from Web Site X to Alice Bob’s Email Provider Alice’s Email Provider

Types of Client-Based Delegation Complete All tokens are forwarded Ideal for combining multiple user accounts Selective Only tokens from site X are forwarded to user Y Choose whether to forward an attempt to change the primary email registered at a site One-time Subset of selective delegation Instead of creating a forwarding rule, the delegator obtains valid authentication tokens and gives them to the delegate

Client-Side Auditing Provide the ability for the client to audit all authentication attempts without modifying the service provider Not possible in password-based approaches Available to SAW because all authentication attempts must pass through the user’s email account Available even when authority has been delegated Retain a copy of the forwarded messages

Summary of Benefits Convenient Secure No site-specific passwords Easy, secure sharing and collaboration Easily automated Web single sign-on No modification to email providers Unilateral deployment by web sites Secure Thwarts all passive attacks Raises the bar for active attackers Removes domino effect of password reuse Reduces attack surface for password phishing

Learn more about SAW Internet Security Research Lab http://isrl.cs.byu.edu