Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "BetterAuth: Web Authentication Revisited Martin Johns, Sebastian Lekies, Bastian Braun, Benjamin Flesch In ACSAC 2012 2013/01/08 A.C. ADL."— 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 2013/01/08 A.C. Chen @ ADL Introduction BetterAuth Protocol Design Implementation Evaluation Conclusion

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 OF WEB ATTACKS

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

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

8 PROTOCOL DESIGN

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

12 PAKE Workflow 2013/01/08 A.C. Chen @ 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

13 Authentication Tracking 2013/01/08 A.C. Chen @ 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

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

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

18 IMPLEMENTATION Native Implementation JavaScript 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-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

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

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

23 EVALUATION Security Evaluation Network-based attacks Other Issues Performance Evaluation Limitation 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 – 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

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

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

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


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

Similar presentations


Ads by Google