Analysing the Security of Google's implementation of OpenID Connect

Many millions of users routinely use their Google accounts to log in to relying party (RP) websites supporting the Google OpenID Connect service. OpenID Connect, a newly standardised single-sign-on protocol, builds an identity layer on top of the OAuth 2.0 protocol, which has itself been widely adopted to support identity management services. It adds identity management functionality to the OAuth 2.0 system and allows an RP to obtain assurances regarding the authenticity of an end user. A number of authors have analysed the security of the OAuth 2.0 protocol, but whether OpenID Connect is secure in practice remains an open question. We report on a large-scale practical study of Google's implementation of OpenID Connect, involving forensic examination of 103 RP websites which support its use for sign-in. Our study reveals serious vulnerabilities of a number of types, all of which allow an attacker to log in to an RP website as a victim user. Further examination suggests that these vulnerabilities are caused by a combination of Google's design of its OpenID Connect service and RP developers making design decisions which sacrifice security for simplicity of implementation. We also give practical recommendations for both RPs and OPs to help improve the security of real world OpenID Connect systems

Managing Identity Management Systems

Although many identity management systems have been proposed, in- tended to improve the security and usability of user authentication, major adoption problems remain. In this thesis we propose a range of novel schemes to address issues acting as barriers to adoption, namely the lack of interoper- ation between systems, simple adoption strategies, and user security within such systems. To enable interoperation, a client-based model is proposed supporting in- terworking between identity management systems. Information Card systems (e.g. CardSpace) are enhanced to enable a user to obtain a security token from an identity provider not supporting Information Cards; such a token, after en- capsulation at the client, can be processed by an Information Card-enabled relying party. The approach involves supporting interoperation at the client, while maximising transparency to identity providers, relying parties and iden- tity selectors. Four specific schemes conforming to the model are described, each of which has been prototyped. These schemes enable interoperation be- tween an Information Card-enabled relying party and an identity provider supporting one of Liberty, Shibboleth, OpenID, or OAuth. To facilitate adoption, novel schemes are proposed that enable Informa- tion Card systems to support password management and single sign on. The schemes do not require any changes to websites, and provide a simple, intu- itive user experience through use of the identity selector interface. They fa- miliarise users with Information Card systems, thereby potentially facilitating their future adoption. To improve user security, an enhancement to Information Card system user authentication is proposed. During user authentication, a one-time pass- word is sent to the user's mobile device which is then entered into the com- puter by the user. Finally, a universal identity management tool is proposed, designed to support a wide range of systems using a single user interface. It provides a consistent user experience, addresses a range of security issues (e.g. phishing), and provides greater user control during authentication.EThOS - Electronic Theses Online ServiceGBUnited Kingdo