Any organisation that processes identity information is required to secure this information, to prevent privacy sensitive data from becoming public. Current identity management frameworks have implemented techniques, methods, and policies to securely handle identity information. However, several vulnerabilities remain.
The IdP is a single point of failure.
As discussed before, identity management systems require the user and the service provider to place a large amount of trust in the IdP. A wealth of identity information is stored at IdPs, and users can do nothing but simply trust the IdP to preserve their privacy and properly secure their identity information. But still, mistakes can be made and privacy-sensitive information can become public (e.g see the Privacy Rights Clearinghouse, ‘Chronology of Data Breaches’. This makes the identity provider a single point of failure.
Possibly even more worrisome is the fact that in most current identity
management systems the IdP has all information it needs to log in at related RPs as a registered user. This means that everybody that has access to this information at the IdP can log in as a user at the related RPs: employees of the IdP, hackers that break into the IdP’s systems, and merely everybody whenever information like this becomes public due to e.g. theft or implementation flaws. Depending on the service, the imposter could order things to make the legitimate user pay money, transfer money from the user’s bank account, or get insight into personal information, such as the user’s electronic health record. The RP has no means to distinguish the impostor from the real user.
The impact of this issue increases as more and more systems get federated and a single IdP is used to access a large number of services. Such an IdP may abuse its powers, maliciously accessing many services, before a user notices. If the RP and the IdP do not properly log authentication requests and access control decisions, both the RP and the IdP may claim that the other party was at fault, and the user will not have any evidence to determine what actually happened.
Recommendation: To prevent this issue it is necessary to put the user in control of information that is released from the IdP, not only by policy, but technically built into the identity management system. It should not be possible for the IdP to log in to a RP claiming to be another user. The identity management system should enforce the requirement that the user controls part of the data necessary to log in to the RP. Cardspace tries to achieve this using the concept of a Priavte Personal Identifier (PPID), and the use of a proof key. This does not solve the problem completely, because the server needs to remember the associated public keys in order to detect spoofing attempts using the same PPID but with freshly generated key pairs. Also, this approach breaks the 8-th law of identity (to be discussed in a later post) on location independence as a special user agent needs to be installed on the user’s PC.
The risk of phishing is increased
Most current identity management systems only provide a way to authenticate the user, but it is not possible for the user to authenticate the IdP or the RP. This is a necessity to be able to prevent phishing attacks, where attackers trick users into revealing identity data and credentials. With identity management becoming more wide-spread, phishing attacks based on getting IdP login credentials will most likely increase as well.
When HTTP redirects are used (as for example in OpenID 1.0) phishing attacks are even easier to launch (see the ‘Beginner’s guide to OpenID phishing’. It is as simple as creating an illegitimate, but attractive, website that redirects to a false copy of the IdP to capture the user’s credentials.
An example countermeasure to phishing attacks using fake IdP websites is Yahoo! sign-in seal. This is a personalised image or short text phrase that will appear each time a user logs in to a Yahoo! web page from the same computer the seal was created on. The presence of the seal enables the user to distinguish the real Yahoo! sign-in page from a false. This solution only works if the user logs in using the same computer as the seal was created on, as Yahoo! identifies it by storing tags in multiple places on the computer.
Recommendation: To prevent phishing attacks it is very important that users can (and will) authenticate the RP and the IdP. Mutual authentication therefore needs to be incorporated in identity management systems, in such a way that the user is not required to install special software or to use one and the same computer all the time (as is the case with Microsoft Cardspace). There does not appear to be a single, usable, and secure fix to prevent phishing in all cases.
What is the optimal size of a key chain? -or- How many identities should a user have?
One of the main advantages of identity management for end-users is single-sign on: not having to remember all those usernames and passwords, but only the log in token for the IdP. From this perspective, wouldn’t it be great to have just one IdP? Only one username/password (or another authentication token) and that’s it.
Of course, this is not feasible. Not only because users may not trust that one IdP to have access to all their services. Even if that is not the case, using only one IdP means that if that IdP is compromised, all identity data is compromised immediately as well. This gives users the incentive to distribute their identity information over multiple IdPs. Furthermore, RPs will require different IdPs. Financial institutions for example have other requirements and preferences than car rental agencies. The first may want to set up their own IdP to be able to control the security of authentication, while the latter is fine with using a third-party IdP. Can we then settle for one IdP for personal use, one for work, and one for each financial institution?
The question is: how many identity providers does a user need? What is the best compartmentalisation of the digital identity mess? We need to understand the advantages and risks of using a certain amount and distribution of IdPs, in terms of security, usability, business.
Recommendation: To be able to determine which and how many ‘identities’ are optimal, a model that captures these relevant aspects needs to be developed. To our knowledge such a model does not exist yet.
Federations are risky
In cross domain settings, one organisation may assign roles to certain
individuals, while another organisation assigns access rights to roles. This is typically done in federation settings: one university classifies certain people as students of that university, while other universities rely on that classification to mediate access to resources like the library, classes, or the student restaurant.
This gives rise to a compliance defect: the IdP may interpret the
semantics of the role (e.g. when someone classifies as a student) differently from the RP, which leads to a situation where a person gets access to a service that he or she is not supposed to access. The reverse (being denied access) is a problem as well.
The above is an instance of a more general issue. Traditionally, access to a resource or service is traditionally mediated through a ‘reference monitor’. In an identity management system, this reference monitor is in a sense distributed over several parties. The underlying question is how to do this split. In the simplest case, this question surfaces as the question where to keep the access rights
A separate issue is the control over the so-called Circle-of-Trust (CoT). By establishing a federation among several IdPs , the CoT is similarly extended. RPs connected to a certain IdP may have limited control over this, and therefore have limited control over the risks that they are exposed to because of the extension of the CoT.
Recommendation: When implementing or joining an identity federation, RPs need to carefully consider where to keep and maintain the access rights. Moreover, they need to judge the consequences when the CoT is extended without their knowledge or consent.
Note: updated 18-2-2017 to fix a broken link.