BetterAuth: Web Authentication Revisited Martin Johns, Sebastian Lekies, Bastian Braun, Benjamin Flesch In ACSAC /01/08 A.C. ADL

Outline 2013/01/08 A.C. ADL Introduction BetterAuth Protocol Design Implementation Evaluation Conclusion

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

REVISIT DOCUMENTED CLASSES OF WEB ATTACKS

Network-Based Issues SSL Stripping [ref][ref] 2013/01/08 A.C. ADL Several CAs’ internal systems have been compromised

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

Current State Exposes Numerous Security 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. ADL

PROTOCOL DESIGN

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

Adopted PAKE Protocol In this paper, we adopt the draft-oiwa-http- mutualauth-10draft-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. ADL

PAKE Workflow 2013/01/08 A.C. ADL http communication Cryptographic values SPK: Server-side Partial Key BPK: Client-side Partial key SSK: Diffie-Hellmann key generated by using the SPK and BPK

Authentication Tracking 2013/01/08 A.C. ADL 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][RFC2104] – all further requests have to attach a correct HMAC signature to be recognized as authenticated

HMAC Workflow 2013/01/08 A.C. ADL sender receiver SSK e.g., For GET requests, the URL in a normalized form and selected request headers are signed as a MAC

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

Which Requests to Sign 1. Test If the target URL points to a valid domain – a valid SSK app 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 SSK app Attach the resulting request signature in an Authorization header to the request 2013/01/08 A.C. ADL

IMPLEMENTATION Native Implementation JavaScript Implementation 2013/01/08 A.C. 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. 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. 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. ADL

Domain Isolated Key Handling 2013/01/08 A.C. ADL

EVALUATION Security Evaluation Network-based attacks Other Issues Performance Evaluation Limitation 2013/01/08 A.C. 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. 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. ADL

JavaScript Implementation Performance 2013/01/08 A.C. ADL times in ms, averaged over ten runs

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. 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 2013/01/08 A.C. ADL