Abstract

OpenID 2.0 is a user-centric Web single sign-on protocol with over one billion OpenID-enabled user accounts, and tens of thousands of supporting websites. While the security of the protocol is clearly critical, so far its security analysis has only been done in a partial and ad-hoc manner. This paper presents the results of a systematic analysis of the protocol using both formal model checking and an empirical evaluation of 132 popular websites that support OpenID. Our formal analysis reveals that the protocol does not guarantee the authenticity and integrity of the authentication request, and it lacks contextual bindings among the protocol messages and the browser. The results of our empirical evaluation suggest that many OpenID-enabled websites are vulnerable to a series of cross-site request forgery attacks (CSRF) that either allow an attacker to stealthily force a victim user to sign into the OpenID supporting website and launch subsequent CSRF attacks (81%), or force a victim to sign in as the attacker in order to spoof the victim's personal information (77%). With additional capabilities (e.g., controlling a wireless access point), the adversary can impersonate the victim on 80% of the evaluated websites, and manipulate the victim's profile attributes by forging the extension parameters on 45% of those sites. Based on the insights from this analysis, we propose and evaluate a simple and scalable mitigation technique for OpenID-enabled websites, and an alternative man-in-the-middle defense mechanism for deployments of OpenID without SSL.

Highlights

  • Back in 2007, a typical web user had about 25 passwordprotected accounts, and entered approximately eight passwords per day (Florencio and Herley, 2007)

  • Several possible threats are documented in the OpenID specification itself, including (1) a phishing attack that redirects users to a malicious replica of an identity provider (IdP) website, (2) the masquerade of an IdP by an MITM attacker between the relying party (RP) and IdP to impersonate users on the RP, (3) a replay attack that exploits the lack of assertion nonce checking by RPs, and (4) a denial-of-service (DoS) attack that attempts to exhaust the computational resources of RPs and IdPs

  • In a non-association mode, the RP has to send the assertion back to the IdP for validation via a direct communication and the validation result is not signed. It is cleardand documented in Section 15.1.2 of the OpenID specification as welldthat an MITM attacker between the RP and IdP could impersonate the victim by replying to the RP with an unsigned positive assertion

Read more

Summary

Introduction

Back in 2007, a typical web user had about 25 passwordprotected accounts, and entered approximately eight passwords per day (Florencio and Herley, 2007). One of the attack traces from our formal model revealed that the RP may accept an authentication response from another session This particular weakness can be exploited in many ways, such as session swapping, sniffing and resetting the user connection, DNS/ARP cache poisoning, or exploiting the exception handling vulnerability in the browser; but the root cause remains the samedthe protocol lacks bindings among the protocol messages and the browser that issued those requests. This work makes the following contributions: (1) a formal specification and analysis of the OpenID protocol that identifies three weaknesses and correlates six types of possible attack vectors, (2) a semi-automatic OpenID vulnerability assessment tool, (3) an empirical evaluation of 132 OpenID-enabled websites, and (4) two proposed and evaluated countermeasures for the attacks that exploit the uncovered weaknesses in the protocol.

Background and related work
Known security issues
Existing defense techniques
Adversary model
The OpenID protocol
Protocol formalization
Alice-Bob formalization
HLPSL formalization
Attack vector evaluations
Manual evaluations
The OpenID vulnerability assessment tool
Evaluation of real-world RPs
Defense mechanisms
The MITM countermeasure
Reference implementation
Limitations
Findings
Conclusion
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call