Chapter 8: Authentication and Authorization

When most people think of security, they think of cryptography, authentication, and authorization. Of course, security is much more than this, but knowing this does not reduce the importance of the three most well-known security technologies. We have already covered some of the Windows Vista cryptographic enhancements in Chapter 7. In this chapter, we focus on some of the new advances in authentication and authorization in Windows Vista, most notably Windows CardSpace and Information Cards, Graphical Identification and Authorization (GINA) changes, and a change we made to the way Owner SIDs work in access controls lists (ACLs.)

Windows CardSpace and Information Cards

Windows CardSpace is Microsoft’s implementation of an Information Card system. Simply put, an Information Card is just a digitally signed XML document used to identify a user. The core developer support for Information Cards is in the .NET Framework 3.0 included in Windows Vista or is available as a download for Windows XP SP2 and later and Windows Server 2003 and later. Support for Information Cards does not require .NET Framework 3.0, but it certainly makes building Information Card aware systems easier. Underlying Windows CardSpace are some of the industry-standard WS-* protocols, including:

• WS-Security (XMLSOAP 2002)

• WS-Trust (XMLSOAP 2005a)

• WS-MetadataExchange (XMLSOAP 2006)

• WS-SecurityPolicy (XMLSOAP 2005b)

All these protocols are covered by Microsoft’s Open Specification Policy (Microsoft 2006a), which means that Microsoft will not enforce any patent or intellectual property rights for the use of these industry standards, even though Microsoft was instrumental in designing some of the standards.

The benefits of Information Cards for service providers (online merchants, banks, etc.) are many, including:

• Stronger client authentication–Even personal cards are more secure than a simple username and password combination.

• Sign-in abandonment reduction–Online merchants do not want users turned away at the point they must enter their credentials. CardSpace makes this process easier, which translates into fewer drop-offs and increased spending by customers.

• Phishing reduction–CardSpace makes it very difficult to mount a successful phishing attack. We discuss this in more detail shortly.

• Convenience–Users do not have to remember passwords.

The Information Card Data Flow

There are usually three main parties involved during an Information Card exchange. The user, also called the subject, must first acquire an Information Card from an Identity Provider using the provider’s security token service (STS); this could be any classic card issuer you are familiar with today, for example, a credit card company or perhaps a digital identity provider such as VeriSign. It is also possible to issue an Information Card to yourself. Note that no specialized hardware is required to use Information Cards–unless the user wishes to use a smartcard.

Next, there is the Relying party, which refers to the entity that wants to know who you are so they can provide a service to you. In our example, we’ll use a fictitious bank, Woodgrove Bank. Figure 8-1 shows the information between the communicating parties.

Figure 8-1: The Information Card communicating parties.

Tip 

You might think user-issued Information Cards are of little use. In fact, they are useful because it’s quite common for a user to create his or her own identity when visiting a Web site for the first time and creating an account at that Web site.

Windows CardSpace and Phishing

Information Cards helps mitigate phishing by employing a number of important security techniques, including:

• Server authentication

• No password to steal! (Seriously!)

• PIN-Protect the user’s Information Cards

• Display Information Card use

Let’s look at each.

Server Authentication

One of the biggest enablers of phishing attacks is poor or nonexistent server authentication; requiring SSL/TLS server authentication goes a long way to remedying the server authentication problem. All communication between the Windows CardSpace client and the server is performed using SSL/TLS, but more importantly, Windows CardSpace requires the SSL/TLS server authenticate correctly to the Windows CardSpace client. In other words, all the appropriate checks are made by Windows CardSpace to make sure the server is who it claims to be. The checks performed by default are as follows:

• Server name the client requests matches the common name in the server certificate.

• The server certificate has not been tampered with.

• Server certificate is trusted (that is, you trust the certificate issuer).

• The date validity is correct.

• The certificate key usage includes server authentication.

• The certificate has not been revoked (may be a local cached lookup).

No Password to Steal!

When a user provides his Information Card–based identity to a server, the user’s password is never provided to the server. Information Cards do not include a password or any other type of secret user credential data. This is absolutely critical, because one of the reasons attackers mount phishing attacks is to harvest unwitting users’ passwords. Rather, a trusted entity, the Identity Provider, attests to the user’s identity.

Also, if the user is using a self-issued Information Card, the key presented to one site is different from the key presented to another site, because the key is derived, in part, from the server’s server authentication certificate.

PIN-Protect the User’s Information Cards

A user can PIN-protect her CardSpace information; the PIN is used to encrypt the CardSpace data, so malware cannot get the user’s CardSpace data unless it can successfully decrypt the data. An AES-256 encryption key is derived from the user’s PIN and a cryptographically unique 128-bit number called a salt after it is passed through a password-based key derivation function (using PKCS#5) for 1,000 iterations. This value will be increased in future versions of Windows.

Display Information Card Use

Finally, when an Information Card is selected, Windows CardSpace shows the historical use of the card and where the Information Card has been used. This is important, because if the site is fraudulent, and all the prior defenses have failed, the user will see that this card has never been used at the phishing site.

Let’s look at all these defenses in action using a fictitious phishing scam.

CardSpace and Phishing–An Example

Let’s assume for a moment that scammers are targeting Woodgrove Bank (www. woodgrovebank.com) customers to get customer account details such as account numbers and passwords. Let’s also assume that Woodgrove Bank requires Information Card identities for all customers when they access their online banking data.

The most common way phishers mount a phishing attack is to send an email that looks like it came from an institution such as Woodgrove Bank, informing the unsuspecting victim that they need to change their password or view an important document–both requiring that the customer enter her credentials. Information Cards cannot help defend against this part of the attack, but perhaps the user’s email client can detect the email is fraudulent.

Let’s assume the worst, and the user clicks the “bank” link in the email. The Web browser opens, and the user is confronted with a Web site that looks just like the real Woodgrove Bank Web site. The site probably includes trademark, copyright, and privacy notices, too! In short, it looks real. But it’s actually a compromised Web server–somewhere on the Internet–that is made to look like Woodgrove Bank, and its sole purpose is to harvest account numbers and passwords of gullible Woodgrove Bank customers.

Again, Information Cards can do nothing here, but perhaps the user’s browser can. Both Internet Explorer 7 and Mozilla FireFox 2 have support for detecting and notifying users of many known phishing sites, as does the Netcraft Toolbar for older browsers (Netcraft 2004).

The connection between Windows CardSpace and the Web server must be over SSL/TLS, and all appropriate SSL/TLS checks are made; otherwise, CardSpace will reject the connection. In other words, the name of the Web site in the browser’s address bar must equal the name in the certificate, and the certificate must be trusted. This will foil most phishing attacks. This has a side effect of breaking some Web sites if they choose to use an SSL/TLS certificate that does not reflect the Web server DNS name. If you want to use Information Cards with your Web site, you should use a valid X.509 certificate, which includes the site’s DNS name in the certificate common name (CN).

Let’s again assume the worst, and the user clicks the option to sign in to the “bank,” regardless of any SSL/TLS warnings issued by the browser. If the user enters her credentials, the rogue Web site now has the user’s logon information. But things are difficult for the phisher. First, for the user to enter her credentials, the logon page must look just like the Windows Card-Space login because Woodgrove Bank uses CardSpace. It is, of course, possible to spoof a user interface, but how will the attacker know what cards the user has and display the user’s cards correctly? Also, how will the attacker know the “visual secrets” chosen by the user? By “visual secrets” we mean the image and text associated with each Information Card (see Figure 8-2).

Figure 8-2: The Windows CardSpace identity selector.

Again assuming the worst, the attack site does not spoof the user’s CardSpace environment but instead invokes the user’s CardSpace environment; the user clicks on an Information Card and enters a PIN to unlock the card. The attacker does not get the user’s credential, even if the credential is a password. Information Cards rely on a trusted third party to assert the user’s identity. The importance of this last point cannot be overstated. The real bank and the attacker never get the user’s password. Ever.

The phishing site will simply get, at best, a token that asserts the user is who the user claims to be. The password is provided to the trusted identity provider, not the phishing site, or the valid site for that matter.

Even if the attacker gets the key from a self-issued card, he cannot replay the key against the real Woodgrove Bank because when a self-issued card is used, the key is derived (in part) from the certificate used by the Web site. Given that the site is different (phisher versus Wood-grove), the generated key is not the same.

Tip 

If you want to see a good technical overview of CardSpace in action, watch the video, “Vittorio Bertocci: WS-Trust–Under the Hood,” on Channel9 (Channel9 2006). Vittorio also has an excellent CardSpace blog (Bertocci 2006) that includes sample code.

Seeing Information Cards in Action

If you want to get started quickly using Windows CardSpace, create a new self-issued Information Card (go to Control Panel [not in classic view], User Accounts, Windows CardSpace) and then point your browser at https://woof.bandit-project.org/wiki/index.php?title=Special:Userlogin, and then click on the Login with the Information Card (Simple) button. Follow the prompts. If all goes well, you should see your username in the Information Card appear as your login name.

What’s in an Information Card?

Information Cards are digitally–signed XML data structures that represent information about the user, known as an assertion. The Information Card is provided by an issuer, and assertion details include the user’s name, date of birth, email address, and so on. Note that assertions are optional and need not contain any personal or private data, but there needs to be at least one assertion in the token. The assertions are described using the Security Assertion Markup Language (SAML) (OASIS 2006), which is a XML-based industry standard. Microsoft’s use of SAML is also covered by Microsoft’s Open Specification Policy (Microsoft 2006a). When a mer- chant wants a user to identify itself, the merchant can request certain assertions, and the Windows CardSpace Identity Selector will allow the user to select an Information Card that supports the required claims.

Programmatically Accessing Information Cards

As we already mentioned, Information Cards support is made easier by using the .NET Framework 3.0 that ships in Windows Vista; the .NET Framework 3.0 is also available as a download for Windows XP SP2 and later and Windows Server 2003 and later.

Information Card functionality is in the System.IdentityModel namespace exported from the C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\System. Identity-Model.dll assembly. Most times, you do not need to explicitly add the assembly reference because the Windows Communication Foundation (WCF) will call the assembly implicitly.

If you want to experiment with Information Cards, you should download the “Accepting information cards in your website (in C#)” sample code from the Windows CardSpace Web site (Microsoft 2006a).

Tip 

We had a couple of problems installing the code on Windows Vista. If you get an exception like this, “Relying Party Certificate thumbprint not specified,” then you should explicitly register capicom by typing regsvr32 capicom.dll in the sample code bin directory.

A Web site can trigger the Windows CardSpace identity selector with HTML code like this:

 <html xmlns="http://www.w3.org/1999/xhtml" > <body>    <form  method="post" action="login.aspx">       <button type="submit">Sign in with your Information Card</button>       <object type="application/x-informationcard" name="xmlToken">          <param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion" />          <param name="issuer"             value="http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self" />          <param name="requiredClaims"             value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname                    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname       </object>    </form> </body> </html>

Note the object tag’s type is application/x-informationcard, and the parameters define what claims the Web site requires from the user, as well as the valid issuer(s). In this case, the Web site will accept self-issued Information Cards that assert the user’s given name and surname.

The login page can then get the data from the user’s Information Card using code like this:

 string xmlToken = Request.Params["xmlToken"]; if (xmlToken == null || xmlToken.Equals("")) {    // Handle Error – there is no token } else {    Token token= new Token(xmlToken);    string givenname = token.Claims[ClaimTypes.GivenName];    string surname = token.Claims[ClaimTypes.Surname];    string email = token.Claims[ClaimTypes.Email]; }

Detecting Information Card Support in the Browser

Detecting browser support for Information Cards requires only a small amount of client-side JavaScript. If the following function returns true, then your Web site can dynamically display a “Please sign in with your information card” interface.

 <script language=Javascript> function AreCardsSupported() {     var IEVer = -1;     // regexp used to get browser version info     var regMSIE = "MSIE ([0-9]{1,}[\.0-9]{0,})";     if (navigator.appName == 'Microsoft Internet Explorer')        if (new RegExp(regMSIE).exec(navigator.userAgent) != null)          IEVer = parseFloat( RegExp.$1 );     // Look for IE 7+ and support for Information Cards.     if( IEVer >= 7 ) {       var obj = document.createElement("object");       obj.setAttribute("type", "application/x-informationcard");         return ( ""+obj.issuerPolicy != "undefined" ) ? true : false;       }     // not IE (any version)     if( IEVer < 0 && navigator.mimeTypes && navigator.mimeTypes.length) {       // check to see if there is a mimeType handler.       x = navigator.mimeTypes['application/x-informationcard'];       if (x && x.enabledPlugin)         return true;     // check for the IdentitySelector event handler is there.     var event = document.createEvent("Events");     event.initEvent("IdentitySelectorAvailable", true, true);     top.dispatchEvent(event);     if( top.IdentitySelectorAvailable == true)      return true;   }   return false; } </script>

The Windows CardSpace Private Desktop

Windows has the concept of multiple desktops; usually a user sees only two–the logon desktop and his usual workspace desktop. There is one logon desktop, and each user has his own desktop ACL’d to the user, which prevents one user from tampering with another user’s session. Windows CardSpace creates its own private desktop for use by CardSpace Identity Selector. The purpose of this is to help reduce the chance that certain kinds of spoofing attacks can occur, most notably screen-scraping attacks.

CardSpace Summary

Nearly two-thirds of this chapter is dedicated to Windows CardSpace and its implementation of the Information Card identity technology, so we want to wrap this section up with a short summary. We feel Information Cards are a very real phishing defense, but we need more people to adopt the technology in both clients and servers. Today, there is Information Card support for many non-Microsoft platforms and technologies, and the list of supported is growing quickly. We highly recommend that you acquaint yourself with Kim Cameron’s blog (Cameron 2006) and the Windows CardSpace resource Web site (Microsoft 2006a) and consider adding Information Card support alongside other identity technologies your system presently supports.