PASTA: PASsword-based Threshold Authentication

Token-based authentication is commonly used to enable a single-sign-on experience on the web, in mobile applications and on enterprise networks using a wide range of open standards and network authentication protocols: clients sign on to an identity provider using their username/password to obtain a cryptographic token generated with a master secret key, and store the token for future accesses to various services and applications. The authentication server(s) are single point of failures that if breached, enable attackers to forge arbitrary tokens or mount offline dictionary attacks to recover client credentials. Our work is the first to introduce and formalize the notion of password-based threshold token-based authentication which distributes the role of an identity provider among $n$ servers. Any t servers can collectively verify passwords and generate tokens, while no t-1 servers can forge a valid token or mount offline dictionary attacks. We then introduce PASTA, a general framework that can be instantiated using any threshold token generation scheme, wherein clients can sign-on using a two-round (optimal) protocol that meets our strong notions of unforgeability and password-safety. We instantiate and implement our framework in C++ using two threshold message authentication codes (MAC) and two threshold digital signatures with different trade-offs. Our experiments show that the overhead of protecting secrets and credentials against breaches in PASTA, i.e. compared to a naive single server solution, is extremely low (1-5%) in the most likely setting where client and servers communicate over the internet. The overhead is higher in case of MAC-based tokens over a LAN (though still only a few milliseconds) due to public-key operations in PASTA. We show, however, that this cost is inherent by proving a symmetric-key only solution impossible

Do not trust me: Using malicious IdPs for analyzing and attacking Single Sign-On

Single Sign-On (SSO) systems simplify login procedures by using an an Identity Provider (IdP) to issue authentication tokens which can be consumed by Service Providers (SPs). Traditionally, IdPs are modeled as trusted third parties. This is reasonable for SSO systems like Kerberos, MS Passport and SAML, where each SP explicitely specifies which IdP he trusts. However, in open systems like OpenID and OpenID Connect, each user may set up his own IdP, and a discovery phase is added to the protocol flow. Thus it is easy for an attacker to set up its own IdP. In this paper we use a novel approach for analyzing SSO authentication schemes by introducing a malicious IdP. With this approach we evaluate one of the most popular and widely deployed SSO protocols - OpenID. We found four novel attack classes on OpenID, which were not covered by previous research, and show their applicability to real-life implementations. As a result, we were able to compromise 11 out of 16 existing OpenID implementations like Sourceforge, Drupal and ownCloud. We automated discovery of these attacks in a open source tool OpenID Attacker, which additionally allows fine-granular testing of all parameters in OpenID implementations. Our research helps to better understand the message flow in the OpenID protocol, trust assumptions in the different components of the system, and implementation issues in OpenID components. It is applicable to other SSO systems like OpenID Connect and SAML. All OpenID implementations have been informed about their vulnerabilities and we supported them in fixing the issues

A standard-driven communication protocol for disconnected clinics in rural areas

The importance of the Electronic Health Record (EHR), which stores all healthcare-related data belonging to a patient, has been recognized in recent years by governments, institutions, and industry. Initiatives like Integrating the Healthcare Enterprise (IHE) have been developed for the definition of standard methodologies for secure and interoperable EHR exchanges among clinics and hospitals. Using the requisites specified by these initiatives, many large-scale projects have been set up to enable healthcare professionals to handle patients' EHRs. Applications deployed in these settings are often considered safety-critical, thus ensuring such security properties as confidentiality, authentication, and authorization is crucial for their success. In this paper, we propose a communication protocol, based on the IHE specifications, for authenticating healthcare professionals and assuring patients' safety in settings where no network connection is available, such as in rural areas of some developing countries. We define a specific threat model, driven by the experience of use cases covered by international projects, and prove that an intruder cannot cause damages to the safety of patients and their data by performing any of the attacks falling within this threat model. To demonstrate the feasibility and effectiveness of our protocol, we have fully implemented it

Layered identity infrastructure model for identity meta systems

There are several Identity Meta Systems emerging in the identity management field, such as CardSpace and Higgins Trust Framework. The goal of an Identity Meta System (IMetS) is to integrate existing or new Identity Management System (IMS) to provide users with seamless interoperability and a consistent user experience. IMetS is a complex system that tries to integrate the already complicated IMS services. With such a complex system, we need a way to assess IMetS in order to determine how well an IMetS integrates the various IMS services. However, as IMetS is a rela- tively new concept, there is no framework to identify the properties that an ideal IMetS should have. The contribution of this paper is to introduce the Layered Identity Infrastructure Model (LIIM) that can be used as a framework to assess IMetS. In addition, the LIIM framework can also be used to identify the missing components of an IMetS, to guide and improve the design of an existing IMetS, to serve as a design benchmark for a new IMetS, as well as to aid the understanding of a complicated IMetS

On Secure Implementation of an IHE XUA-Based Protocol for Authenticating Healthcare Professionals

The importance of the Electronic Health Record (EHR) has been addressed in recent years by governments and institutions.Many large scale projects have been funded with the aim to allow healthcare professionals to consult patients data. Properties such as confidentiality, authentication and authorization are the key for the success for these projects. The Integrating the Healthcare Enterprise (IHE) initiative promotes the coordinated use of established standards for authenticated and secure EHR exchanges among clinics and hospitals. In particular, the IHE integration profile named XUA permits to attest user identities by relying on SAML assertions, i.e. XML documents containing authentication statements. In this paper, we provide a formal model for the secure issuance of such an assertion. We first specify the scenario using the process calculus COWS and then analyse it using the model checker CMC. Our analysis reveals a potential flaw in the XUA profile when using a SAML assertion in an unprotected network. We then suggest a solution for this flaw, and model check and implement this solution to show that it is secure and feasible

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