1 / 28

BetterAuth : Web Authentication Revisited

BetterAuth : Web Authentication Revisited. Martin Johns, Sebastian Lekies , Bastian Braun, Benjamin Flesch In ACSAC 2012. Outline. Introduction BetterAuth Protocol Design Implementation Evaluation Conclusion. Web Authentication Process. 1. Initial authentication

manasa
Download Presentation

BetterAuth : Web Authentication Revisited

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

  4. revisit documented classes ofWeb attacks 2013/01/08 A.C. Chen @ ADL

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

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

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

  8. PROTOCOL DESIGN 2013/01/08 A.C. Chen @ ADL

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

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

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

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

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

  14. HMAC Workflow receiver SSK SSK sender 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

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

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

  17. Which Requests to Sign 1. Test 2. Action Normalize the request data create an HMAC signature using SSKapp Attach the resulting request signature in an Authorization header to the request • 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 2013/01/08 A.C. Chen @ ADL

  18. Native Implementation JavaScript Implementation Implementation 2013/01/08 A.C. Chen @ ADL

  19. Native Implementation • Firefox extension • hooks itself as an observer into the browser’s rendering process • intercepts the BetterAuth-Enabledform 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

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

  21. Isolating the Key Material • A separate subdomainonly 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

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

  23. Security Evaluation Network-based attacks Other Issues Performance Evaluation Limitation Evaluation 2013/01/08 A.C. Chen @ ADL

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

  25. Other Issues • Session hijacking and fixation attacks do not apply • no authentication cookie • CSRF attacks are mitigated • crossdomainrequests 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

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

  27. 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-BetterAuthform field • Limited protection against Clickjacking • the public interfaces should still be protected with anti-framing measures 2013/01/08 A.C. Chen @ ADL

  28. 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. Chen @ ADL

More Related