Windows Live ID is the latest stage in the evolution of Microsoft’s Passport service and is used to authenticate to Microsoft’s core web applications, including MSN, Hotmail, Messenger, Xbox Live, Channel9, among others. A Windows Live ID is a digital identity consisting of one or more claims that are used to authenticate users to the Windows Live ID authentication service. These claims may be comprised of information such as a user’s e-mail address, the organization(s) that user belongs to, and the roles, relationships, and other authorization-related data associated with the user. Authentication is accomplished through the use of a username/password pair, strong passwords and security PIN combinations, smart cards, or self-issued Windows CardSpace cards. The Windows Live ID service also supports specialized mechanisms such as RADIUS protocol to authenticate nonstandard devices including cell phones and the Xbox 360.
The basic process behind Windows Live ID authentication is this: First, the user attempts to authenticate against a site relying on the Windows Live ID authentication service. Assuming the user is not currently authenticated, she will be redirected to the Windows Live ID authentication site with information about the site she is trying to authenticate to (say, Channel9.msdn.com) in the redirect. The user will then be prompted to enter her Windows Live ID authentication credentials, typically a username and password, and if the authentication attempt succeeds, a number of authentication tokens will be returned in a form in the response. The form will point back to the site that the user is attempting to authenticate against (Channel9), and JavaScript in the response will
automatically post the form to convey the authentication tokens to Channel9, thereby successfully completing the authentication process. The form method for conveying the authentication tokens is necessary to communicate the authentication tokens from the live.com domain, where the Windows Live ID service exists, to the Channel9.msdn.com domain, where Channel9 currently resides.
When the target application also exists under the live.com domain (as is the case with Hotmail), the authentication tokens are typically directly set in cookies in the response HTTP header. However, form-based token storage is necessary when the target domain (e.g., channel9.mdsn.com) is different than the Windows Live domain (e.g., live.com) due to the browser-enforced same-origin policy that prevents one domain from accessing the cookie values set in another domain.
A common theme across many of these analyses suggests that one of the biggest dangers in using Windows Live ID authentication is replay attacks using authentication cookies stolen from unsuspecting users’ computers. Of course, assuming an attacker could steal authentication tickets would probably defeat most authentication systems out of the gate, as we noted in our earlier discussion of security token replay attacks in this chapter.
Like any other authentication system, Windows Live ID is also potentially vulnerable to password-guessing attacks (the minimum password length is six characters, with no requirements for different case, numbers, or special characters). Although there is no permanent account lockout feature, after a certain number of failed login attempts, an account will be temporarily prevented from logging in (this lasts a “few moments”
according to the error message). This is designed to add significant time to online password-guessing attacks.
Windows Live Delegated Authentication The Windows Delegated Authentication service allows application developers to leverage externally exposed Windows Live authentication web services to interact and retrieve data associated to a specific Windows Live ID and service. For example, a developer could create an application to connect and retrieve Windows Live Contacts data (used by Hotmail, Messenger, and Mobile) for use in his or her own application. In Microsoft’s terminology, the Windows Live Contacts API providing access to the contacts data is known as the resource provider and the application connecting to that is called the application provider. For the access attempt to succeed, a user must permit the operation through the consent user interface. The lifetime and validity of the consent, as well as the scope of the data access permitted, can be adjusted at any time by the end-user.
When a user provides permission through the consent UI for an application provider to access a resource provider, a consent token and delegation token are returned to the application provider for use in subsequent operations. The combination of these two tokens is required for the application provider to authenticate subsequent operations to access data protected by the resource provider. The consent token contains information defining the “offers” and “actions” the user has permitted the application provider to access as well as other important data needed by the application provider. The delegation token is an encrypted block of data contained within the consent token that must be passed to the resource provider when executing operations to retrieve or manipulate
authenticated user data. It is important to note that delegation tokens can be used to authenticate to the resource provider even if the corresponding user has logged out of Windows Live. However, the lifetime of the consent and delegation token is defined by the end-user.
While delegated authentication does provide developers with the flexibility they need to create applications integrated with Microsoft resource providers, it does so at some additional security risk to end-users. First, there is always the risk that an application provider is compromised, resulting in both the disclosure of active authentication tokens to unauthorized parties and access to locally cached data originating from the resource provider. This potential disclosure increases the overall attack surface of the data accessible through the resource providers.
Of course, there is always the risk of a malicious user registering a nefarious application provider and luring unsuspecting or gullible users (who are, let’s face it, a dime a dozen) into providing consent to access resource providers. Although this risk deserves consideration, it is not significantly different from a normal phishing attack.
OpenID
OpenID is a user-centric, decentralized authentication system providing services identical to that of Windows Live ID. The key difference is that in OpenID, there is no central authentication provider. Any number of organizations can become providers, allowing for greater choice and flexibility.
The process of authenticating to a site, referred to as a relying party (previously OpenID consumer), is simple. First, a nonauthenticated user visits a web site supporting OpenID—for this example, let’s say slashdot.com— and selects OpenID as his method of authentication. The user is then prompted to provide a URL that specifies his unique identity on the provider he has selected. For example, one popular provider, MyOpenID (www.myopenid.com), creates URLs of the form <username>.myopenid.com, where
<username> is the name selected when the MyOpenID account was created. When the user attempting to authenticate to the relying party (Slashdot) supplies this URL, he is redirected to a login page at the provider site (MyOpenID) that prompts for the password selected when the account was created. If the user provides the correct password, he will be redirected back from the OpenID provider to the original site as an authenticated user.
From this point, he may be asked to complete profile-related information if this is the first time he has authenticated with the site.
This example uses passwords as the required authentication credentials, although this is not mandated by the OpenID specification. Not mandating the type of credentials to be used allows authentication providers to support any number of credential types such as client-side certificates, biometric devices, or smart cards.
The biggest downside to using OpenID is that a single compromise of the OpenID account credentials will result in the compromise of every OpenID web application used by the victim user until that point. While the attacker may not know what applications those are, it is trivial to enumerate the popular sites until the attacker strikes upon something interesting. This risk can be mitigated through enforcing strong passwords, rotating passwords on a periodic basis, or simply by selecting a stronger authentication
method such as client-side certificates and other digital identity systems such as Windows CardSpace.
The risk of credential theft is heightened by the ease with which attackers can dupe users into providing these credentials at malicious OpenID phishing sites. When talking about OpenID security, this issue is often the first raised. For example, it is trivial to create a web site that appears to accept a normal OpenID provider URL yet on the backend redirects the authenticating user to an attacker-controlled web site constructed to resemble the selected provider. Unless users are paying careful attention to the web site they have been redirected to, it is unlikely they will notice the attack until it is too late (if at all). Other security considerations have been enumerated in the OpenID 2.0 authentication specification, a link to which can be found in the “References & Further Reading” section at the end of this chapter.
As part of a phishing-resistant authentication solution for OpenID, in February 2007, Microsoft announced a partnership with JanRain, Sxip, and VeriSign to collaborate on integration of Microsoft Windows CardSpace digital identity platform technology into OpenID implementations. Because CardSpace relies on the use of digital identities backed by cryptographic technologies, attackers will have a hard time impersonating clients without directly compromising the digital identities stored on the client machine.
More information regarding Microsoft Windows CardSpace is provided in the next section.
While not security related, another downside to OpenID is that it has yet to be adopted by many of the major players in the online community. While Microsoft, Google, and Yahoo! now serve as OpenID providers, none of these organizations currently consumes these identities for use in their most popular web properties. In other words, users will not be using a Google-based OpenID account to log in to Hotmail anytime soon.