BetterAuth: Web Authentication Revisited

Martin Johns, Sebastian Lekies, Bastian Braun, Benjamin Flesch

In ACSAC 2012

2013/01/08 A.C. Chen @ ADL

2013/01/08 A.C. Chen @ ADL

Outline

• Introduction• BetterAuth Protocol Design• Implementation• Evaluation• Conclusion

2013/01/08 A.C. Chen @ ADL

Web Authentication Process

• 1. Initial authentication– user provides ID and password – the browser create an HTTP request to the

server

• 2. Authentication tracking– use HTTP cookies to maintain an

authenticated state

2013/01/08 A.C. Chen @ ADL

REVISIT DOCUMENTED CLASSES OFWEB ATTACKS

2013/01/08 A.C. Chen @ ADL

Network-Based Issues• SSL Stripping [ref] • Several CAs’ internal

systems have been compromised

2013/01/08 A.C. Chen @ ADL

Other Issues

• Cookie-Based Authentication Tracking Issues– Session hijacking through cookie theft– Session Fixation– Cross-site Request Forgery– Clickjacking

• Phishing– no straight forward technical solution, as long

as the passwords are still sent over the wire

2013/01/08 A.C. Chen @ ADL

Current State Exposes NumerousSecurity Shortcomings

• Existing measures have to be explicitly introduced and are realized at different positions and abstraction levels within the application architecture

• The basic interaction pattern is still susceptible to phishing attacks• the current scheme requires sending the password to

the server as part of each login process

2013/01/08 A.C. Chen @ ADL

PROTOCOL DESIGN

2013/01/08 A.C. Chen @ ADL

High-level Overview

• Two steps, implemented as subprotocols:– Initial mutual authentication protocol• the browser and the server jointly generate a per-

session, shared secret used for further authentication tracking

– Authentication tracking scheme• every further request from the browser to the

server is signed using the freshly generated shared secret if the request satisfies certain criteria

2013/01/08 A.C. Chen @ ADL

Sending Password via Wire is Dangerous

• PAKE (Password-Authenticated Key Exchange) protocol– allows two parties who share knowledge of a

password to mutually authenticate each other and establish a shared key

2013/01/08 A.C. Chen @ ADL

Adopted PAKE Protocol

• In this paper, we adopt the draft-oiwa-http-mutualauth-10– currently under active standardization by the

IETF– designed as an extension to the HTTP

protocol

• Mainly 3 Steps– Initial Handshake– Key exchange–Mutual authentication

2013/01/08 A.C. Chen @ ADL

PAKE Workflow

http communication

Cryptographic values

SPK: Server-side Partial KeyBPK: Client-side Partial keySSK: Diffie-Hellmann key generated by using the SPK and BPK

2013/01/08 A.C. Chen @ ADL

Authentication Tracking

• Ensure both the authenticity as well as the integrity of the received requests– SSK serve as the basis for authentication

tracking

• Realized by Keyed-Hashing for Message Authentication (HMACs) [RFC2104]– all further requests have to attach a correct

HMAC signature to be recognized as authenticated

2013/01/08 A.C. Chen @ ADL

HMAC Workflow

sender

receiver

SSK SSK

e.g., For GET requests, the URL in a normalized form and selected request headers are signed as a MAC

2013/01/08 A.C. Chen @ ADL

Context-Dependent Authentication

• In-application authentication tracking– BetterAuth only signs outgoing requests if the

request’s origin is already in an authenticated state with the server

– inflexible to cater to all existing usage patterns of the Web• public interface

2013/01/08 A.C. Chen @ ADL

Public Interfaces

• A public interface is a URL to which external sites are allowed to navigate in an authenticated state (e.g., for posting to social sharing sites )– a Web application’s public interfaces are

communicated to the browser during the initial key exchange

2013/01/08 A.C. Chen @ ADL

Which Requests to Sign

1. Test• If the target URL points to a valid

domain– a valid SSKapp key could be

found in the key storage

• If the request is entitled to be signed– the request was generated

in the origin of the authenticated application

– the target of the request contained in the public interfaces

2. Action• Normalize the request data

– create an HMAC signature using SSKapp

• Attach the resulting request signature in an Authorization header to the request

2013/01/08 A.C. Chen @ ADL

IMPLEMENTATION

Native Implementation JavaScript Implementation

2013/01/08 A.C. Chen @ ADL

Native Implementation

• Firefox extension– hooks itself as an observer into the browser’s

rendering process • intercepts the BetterAuth-Enabled form to initialize

authentication– custom attribute data-purpose= “betterauth”

• signs the outgoing request if the request origin is valid

2013/01/08 A.C. Chen @ ADL

JavaScript Implementation

• Replace native navigation operations– execute the initial authentication handshake– sign every outgoing requests by JavaScript

before they are sent to the server

• Main elements:– a dedicated form handling the initial

authentication– a request signing component– a dedicated page loader object for page

transitions

2013/01/08 A.C. Chen @ ADL

Isolating the Key Material

• A separate subdomain only contains static JavaScript dedicated to handling and storing the signing key– postMessage API• two browser documents are able to communicate

across domain boundaries in a secure manner• postMessage(message, targetOrigin)• origin checking, prevents potential abuse

2013/01/08 A.C. Chen @ ADL

Domain Isolated Key Handling

2013/01/08 A.C. Chen @ ADL

EVALUATION

Security Evaluation• Network-based attacks• Other Issues

Performance EvaluationLimitation

2013/01/08 A.C. Chen @ ADL

Network-based attacks

• Sniffing attacks are powerless– neither passwords nor authentication tokens

are transmitted over the network

• Man-in-the-middle attacks are mitigated– due to the mutual authentication properties

• SSL stripping attacks or CA breaches have no effect– BetterAuth does not rely on the security of an

underlying SSL/TLS connection

2013/01/08 A.C. Chen @ ADL

Other Issues

• Session hijacking and fixation attacks do not apply– no authentication cookie

• CSRF attacks are mitigated– crossdomain requests are treated as

unauthenticated by default

• Phishing attacks are bound to fail– the password never leaves the browser

2013/01/08 A.C. Chen @ ADL

JavaScript Implementation Performance

times in ms, averaged over ten runs

2013/01/08 A.C. Chen @ ADL

Limitations

• The protection of the password can be circumvented by the attacker on the GUI-level– the user can be tricked into entering his

password in non-BetterAuth form field

• Limited protection against Clickjacking– the public interfaces should still be protected

with anti-framing measures

2013/01/08 A.C. Chen @ ADL

Conclusion

• BetterAuth : a mutual Web authentication protocol– spans the full authentication lifecycle– allows a pure JavaScript fallback for browsers

which do not support the proposed scheme natively

– significantly improves the susceptibility of the authentication process to known threats