Breaking and Fixing Mobile App Authentication with OAuth2.0-based Protocols

Yang, Ronghai; Lau, Wing Cheong; Shi, Shangcheng

doi:10.1007/978-3-319-61204-1_16

Cited by 13 publications

(3 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…However, none of them ensures that the identity tokens are sent to the designated RP only [35,36], because a WebView or the system browser cannot authenticate the RP Apps and the IdP App may be repackaged. The SSO protocols are modified to work for mobile Apps, but these modifications are not well understood by RP developers [35,37]. Vulnerabilities were disclosed in lots of Android applications, to break confidentiality [35][36][37][38], integrity [35,37], and RP designation [35,38] of SSO identity tokens.…”

Section: Extended Related Workmentioning

confidence: 99%

“…The SSO protocols are modified to work for mobile Apps, but these modifications are not well understood by RP developers [35,37]. Vulnerabilities were disclosed in lots of Android applications, to break confidentiality [35][36][37][38], integrity [35,37], and RP designation [35,38] of SSO identity tokens. A software flaw was found in Google Apps [23], allowing a malicious RP to hijack a user's authentication attempt and inject a payload to steal the cookie (or identity token) for another RP.…”

Section: Extended Related Workmentioning

confidence: 99%

See 1 more Smart Citation

UPPRESSO: Untraceable and Unlinkable Privacy-PREserving Single Sign-On Services

Guo¹,

Lin²,

Cai³

et al. 2021

Preprint

View full text Add to dashboard Cite

Single sign-on (SSO) allows a user to maintain only the credential at the identity provider (IdP), instead of one credential for each relying party (RP), to login to numerous RPs. However, SSO introduces extra privacy leakage threats, compared with traditional authentication mechanisms, as (a) the IdP could track all the RPs which a user is visiting, and (b) collusive RPs could learn a user's online profile by linking his identities across these RPs. Several privacy-preserving SSO solutions have been proposed to defend against either the curious IdP or collusive RPs, but none of them addresses both of these privacy leakage threats at the same time.In this paper, we propose a privacy-preserving SSO system, called UPPRESSO, to protect a user's login traces against both the curious IdP and collusive RPs simultaneously. We analyze the identity dilemma between the SSO security requirements and these privacy concerns, and convert the SSO privacy problems into an identity-transformation challenge. In each login instance of UPPRESSO, an ephemeral pseudo-identity (denoted as PID RP ) of the RP which the user is attempting to visit, is firstly negotiated between the RP and the user. Then, PID RP is sent to the IdP and designated in the identity token, so that the IdP is not aware of the visited RP. Meanwhile, PID RP is used by the IdP to transform the permanent user identity ID U into an ephemeral user pseudo-identity (denoted as PID U ) in the identity token. On receiving the identity token, the RP transforms PID U into a permanent account (denoted as Acct) of the user, by a trapdoor in the negotiation. Given a user, the account at each RP is unique and different from ID U , so collusive RPs cannot link his identities across multiple RPs. To the best of our knowledge, this is the first practical SSO solution which solves the privacy problems caused by both the curious IdP and collusive RPs.We build the UPPRESSO prototype system for web applications, with standard functions of OpenID Connect (OIDC): the function of RP Dynamic Registration is used to support ephemeral PID RP , while the function of Core Sign-On is slightly modified to calculate PID U and Acct. The prototype system is implemented on top of open-source MITREid Con-nect, and the extensive evaluation shows that UPPRESSO introduces reasonable overheads and fulfills the requirements of both security and privacy.

show abstract

Section: Extended Related Workmentioning

confidence: 99%

Section: Extended Related Workmentioning

confidence: 99%

UPPRESSO: Untraceable and Unlinkable Privacy-PREserving Single Sign-On Services

Guo¹,

Lin²,

Cai³

et al. 2021

Preprint

View full text Add to dashboard Cite

show abstract

“…They also disclosed four scenarios where the state parameter can be misused by RP developers. Most recently, Yang, Lau and Shi [26] conducted a large scale study of Android OAuth 2.0-based SSO systems. They found three previously unknown security flaws among first-tier identity providers and a large number of popular third party apps.…”

Section: Rp → Uamentioning

confidence: 99%

OAuthGuard: Protecting User Security and Privacy with OAuth 2.0 and OpenID Connect

Li¹,

Mitchell²,

Chen³

2019

Preprint

View full text Add to dashboard Cite

Millions of users routinely use Google to log in to websites supporting OAuth 2.0 or OpenID Connect; the security of OAuth 2.0 and OpenID Connect is therefore of critical importance. As revealed in previous studies, in practice RPs often implement OAuth 2.0 incorrectly, and so many real-world OAuth 2.0 and OpenID Connect systems are vulnerable to attack. However, users of such flawed systems are typically unaware of these issues, and so are at risk of attacks which could result in unauthorised access to the victim user's account at an RP. In order to address this threat, we have developed OAuthGuard, an OAuth 2.0 and OpenID Connect vulnerability scanner and protector, that works with RPs using Google OAuth 2.0 and OpenID Connect services. It protects user security and privacy even when RPs do not implement OAuth 2.0 or OpenID Connect correctly. We used OAuthGuard to survey the 1000 topranked websites supporting Google sign-in for the possible presence of five OAuth 2.0 or OpenID Connect security and privacy vulnerabilities, of which one has not previously been described in the literature. Of the 137 sites in our study that employ Google Sign-in, 69 were found to suffer from at least one serious vulnerability. OAuthGuard was able to protect user security and privacy for 56 of these 69 RPs, and for the other 13 was able to warn users that they were using an insecure implementation.

show abstract