1. 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

2. 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.

3. 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

4. Background Email-Based Password Reestablishment (EBPR) SAW’s Approach
Many sites use 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

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
From:
To:
Subject: [SAW- AT =2fe32...
Click on the link below ONLY if you recently initiated a
request to log in to
User’s Provider

6. Alternatives to Email & Automation
SAW can leverage other personal messaging mediums
Instant messaging
Text messaging
Paging messaging
Hybrid (e.g., + 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
Total login time using IM
Gmail Account
2.5s 4s
<1s
Private Account 1s
1.5s
n/a

7. 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 address
SAW does not prevent users from divulging other sensitive information to a phishing site
Compromised Server
No user passwords to steal

8. Active Impersonation Attack
Attacker
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
The hybrid approach can be used to increase the difficultly of an active impersonation attack
Victim’s Provider

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

10. Sharing and Collaboration
Specify the users that can have access
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

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

12. Client-Based Delegation Example
Bob delegates access to Alice
Step 1:
Alice submits Bob’s
address
Step 2:
Server actions remain the same
Bob’s 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 Provider
Alice’s Provider

13. 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 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

14. 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 account
Available even when authority has been delegated
Retain a copy of the forwarded messages

15. Summary of Benefits Convenient Secure No site-specific passwords
Easy, secure sharing and collaboration
Easily automated
Web single sign-on
No modification to 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

16. Learn more about SAW Internet Security Research Lab