BetterAuth : Web Authentication Revisited
description
Transcript of BetterAuth : Web Authentication Revisited
![Page 1: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/1.jpg)
BetterAuth: Web Authentication Revisited
Martin Johns, Sebastian Lekies, Bastian Braun, Benjamin Flesch
In ACSAC 2012
2013/01/08 A.C. Chen @ ADL
![Page 2: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/2.jpg)
2013/01/08 A.C. Chen @ ADL
Outline
• Introduction• BetterAuth Protocol Design• Implementation• Evaluation• Conclusion
![Page 3: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/3.jpg)
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
![Page 4: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/4.jpg)
2013/01/08 A.C. Chen @ ADL
REVISIT DOCUMENTED CLASSES OFWEB ATTACKS
![Page 5: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/5.jpg)
2013/01/08 A.C. Chen @ ADL
Network-Based Issues• SSL Stripping [ref] • Several CAs’ internal
systems have been compromised
![Page 6: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/6.jpg)
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
![Page 7: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/7.jpg)
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
![Page 8: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/8.jpg)
2013/01/08 A.C. Chen @ ADL
PROTOCOL DESIGN
![Page 9: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/9.jpg)
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
![Page 10: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/10.jpg)
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
![Page 11: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/11.jpg)
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
![Page 12: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/12.jpg)
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
![Page 13: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/13.jpg)
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
![Page 14: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/14.jpg)
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
![Page 15: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/15.jpg)
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
![Page 16: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/16.jpg)
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
![Page 17: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/17.jpg)
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
![Page 18: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/18.jpg)
2013/01/08 A.C. Chen @ ADL
IMPLEMENTATION
Native Implementation JavaScript Implementation
![Page 19: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/19.jpg)
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
![Page 20: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/20.jpg)
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
![Page 21: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/21.jpg)
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
![Page 22: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/22.jpg)
2013/01/08 A.C. Chen @ ADL
Domain Isolated Key Handling
![Page 23: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/23.jpg)
2013/01/08 A.C. Chen @ ADL
EVALUATION
Security Evaluation• Network-based attacks• Other Issues
Performance EvaluationLimitation
![Page 24: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/24.jpg)
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
![Page 25: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/25.jpg)
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
![Page 26: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/26.jpg)
2013/01/08 A.C. Chen @ ADL
JavaScript Implementation Performance
times in ms, averaged over ten runs
![Page 27: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/27.jpg)
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
![Page 28: BetterAuth : Web Authentication Revisited](https://reader036.fdocuments.us/reader036/viewer/2022062309/56814583550346895db26144/html5/thumbnails/28.jpg)
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