I have working with, writing about and presenting on CardSpace for over 2.5 years now...and in the process refining how I describe to people the benefits of information cards for improving security for end-users. In particular, end-users that are not like us developers...every day people that don't know how to choose which sites are unsafe, which links to click in email, and so on.

Consider the following malicious PayPal email:

You can see that the "Click here to verify your information" link is not really sending you to the PayPal site. I see this because I hover over the link to verify the destination...but most non-developers won't know to do this. For those unsuspecting users the story might play like this:

• They go to the destination site, which might look just like the PayPal site. 
• They try to log in, it fails repeatedly. In the meantime, they enter every combination of username and password they use in various sites...perhaps including their online banking site.
• The malicious site collects these combinations of username and password.
• The user gives up logging in.
• The malicious sites now tries to log in to the real PayPal account, or worse, to some of the major well-known online banking sites.
• If they are lucky, and the user is unlucky, one of those username and password combinations will work at the online banking site, and they can write themselves a check, or otherwise play havoc on the user's bank account.

It is that easy to lift a username and password combination.

So, how do information cards issued by CardSpace (or, any other identity selector) help?

Let's assume that the user has associated a personal card with their PayPal account...if PayPal supported information cards. The same scenario might go like this:

• The user get's the evil email. They click the link and head to the malicious site that looks just like PayPal.
• If the site doesn't support information cards, the user will be suspicious because they always log in with a card.
• If the site shows support for information cards, the user may fall for it and click on the "log in with personal card" link which takes them to CardSpace.
• CardSpace will ask you to confirm the site by reviewing its privacy statement and site identity. This should trigger an indication to the user that this is not the site they think it is, since they would normally only get this the first time they hit the site. If they have logged in to PayPal before with a card, they wouldn't see this screen:

• Assuming this isn't enough to tip off the user, and they continue, the next strange behavior will be that they are asked to select a card to send to the site...but there will not be any list of cards already used at this site.

They should have seen at least one personal card present as shown here:

• Assuming this is still not enough to tip off the user, and they decide to select a card to send...the destination site will receive a security token with the requested claims which may include any personal information that you can enter into a personal card such as name, address, phone number, date of birth, and your card's private personal identifier (PPID). BUT, if the site requests more claims than PayPal, there are still more indicators of the malicious site. The first is that you'll be informed that the site is requesting new claims:

• This should really stop the user in their tracks, but they can preview the data requested and decide if they are comfortable sharing this data as shown here:

• If the malicious site wants any data I never share with PayPal, the user would probably stop here. But, let's say they continue and add the data, or, let's say they already had entered the data for this card so it wasn't necessary to provide it here. For example, I might create a personal card with my home and business details in full...but that doesn't mean I send all those claims to every site. Perhaps only to my online banking site because they require an address and phone number to help prove who I am sending the card. So, if the card already has all the details, the user is still warned that new claims were requested and should be approved:

• The user can (and should) preview the requested data. In fact I think that CardSpace should force the user to preview it the first time. Furthermore the new data requested should be called out in red here...so it is obvious.

• Now, the user is ultimately responsible for approving sending the information to the malicious site after all of these indicators that something is amiss. But, let's say that they proceed and send the information. What happens then?
• The site get's a signed security token with your name, address, phone number, date of birth details. Nothing so risky as a SSN or passport number.
• The same token carries the card PPID, however this PPID will not be the same PPID as that used for PayPal because every site gets its own PPID for the card.

So, what can the malicious site do with all this information? Can they log in to PayPal now?

• No, because they don't have the PPID and presumably PayPal has associated their own PPID with the account, not the same as the one the malicious site received.

What else can go wrong? A malicious party could somehow get their hands on the PPID information. This wouldn't be so easy, since the security token issued by CardSpace is always encrypted when sent...but once it arrives to PayPal site it is open and available for view, and someone could look over your shoulder as you view your card to send to PayPal and see the PPID for PayPal right there. If this happens, there is another security measure available.

Each personal card has a private key associated with it - called a master key. That master key is used to sign the security token sent to the site. Only your exact card installed in CardSpace can sign the token with this private key. Thus, if the site associates the PPID + hash of the master key cert with your account, only tokens signed with the correct private key carrying the correct PPID will be authenticated. A malicious party cannot get the master key unless they export your cards from the machine, and import to their machine. Hopefully the user has a password on their laptop. Hopefully if they export cards and import to another machine, they do it safely and destroy the copy they put temporarily on the USB drive to transfer the cards.

Still, this is MUCH MORE SECURE than the username and password we use today...because now a malicious party has to get physical access to a user's machine or USB drive with exported cards...and figure out the password protection in the latter case since exported cards are encrypted.

Hopefully this helps explain how CardSpace and personal cards HELP sites to protect users...better than username and password to today.

As some of you may know, several of us at IDesign (Juval, Brian and myself) are in the midst of a two-week .NET 3.5 Roadshow - six cities in two weeks where we collectively cover WCF, WF, WPF, CardSpace, federated and claims-based security concepts, and some key aspects of .NET 3.5 such as new C# 3.0 language features and ADO.NET 3.5 including LINQ and the Entity Framework.

I'm personally covering WCF security, federated and claims-based security, C# 3.0 and ADO.NET 3.5. For those of you attending (or, not) here are links to the code samples I'm presenting:

VS 2005 samples

• WCF Security Fundamentals - these samples come from the \Security directory from my book code
• Federated and Claims-Based Security in WCF - these samples come from the \Security\ClaimsBased directory from my book code
• CardSpace Samples

Download VS 2008 Samples (UPDATED 10/11/07)

This download includes all samples referenced above, in addition to .NET 3.5 samples for C# 3.0 and LINQ, and IDesign's declarative security model including a recent version of our ServiceModelEx library.  

Other relevant resources discussed:

• My WCF webcast series
• CardSpace controls for ASP.NET
• IDesign articles

Any questions? Email me.

-Michele

Once again a fantastic conference in Orlando. Dev Connections just keeps getting better and I always enjoy being part of it. Not to mention the weather in Orlando isn't bad!

Here are links to my code samples for each talk I delivered. Enjoy!

.NET Technology Roadmap Tutorial

• This tutorial provides an overview of all the key Microsoft technologies for today, tomorrow and the forseeable future - to help you understand and weigh choices for building web, windows and SOA applications.
• Links to the tutorial code can be found in this blog entry (keep an eye out for updates, additions over time):
• http://www.dasblonde.net/2007/03/23/MakingSenseOfTheMicrosoftTechnologyAvalanche.aspx

ASP.NET and WCF

• All of my WCF samples for my book can be found here: http://www.thatindigogirl.com/LearningWCFCode.aspx

ASP.NET and CardSpace

• Demonstrations in this talk can be found here:
  • http://www.dasblonde.net/downloads/code/CardSpaceSamples.zip

WCF Federated Security

• My claims-based samples can be found here:
  • http://www.dasblonde.net/downloads/code/ClaimsBasedSamples.zip
• And, my STS sample here (NOTE: this sample will be updated shortly with an upcoming article, stay tuned!):
  • MediaServicesFederation.zip (2.07 MB)

 WCF Contracts and Versioning

• All of my WCF samples for my book can be found here: http://www.thatindigogirl.com/LearningWCFCode.aspx
• See ServiceContracts, DataContracts and AdvancedSerialization directories.

ASP.NET Performance (Updated 06/07/2007)

Ok people, I had this in my Windows Live Writer to send a long time ago, and somehow it did not post...but since I haven't posted in a while I didn't notice. Many apologies for the delay. Does the "better late than never" statement apply here? I hope so...

• In this talk I covered a lot of ground, and theory around performance including simpler performance tips, the progression of asynchronous handlers to component distribution, and the importance of performance counters for your SLAs.
• You can look at my ASP.NET Sandboxing articles and samples for more resources on component distribution.
• ASP.NET Sandboxing - Part 1
• Code updated for ASP.NET 2.0: ASPNETSandboxing_updatedfor2.0.zip 
• ASP.NET Sandboxing - Part 2
• Code updated for ASP.NET 2.0: ASPNETSandboxing2_updatedfor2.0.zip
• See also the following data demos for examples of data caching
• DataDemos.zip
• DataAccessComparison.zip (this is a simple demo illustrating performance benefits of data reader over data set)
• My LocalizedGallery globalization example (posted here) illustrates the use of complex output caching based on custom caching by browser, culture and profile
• Asynchronous HTTP handlers:
• Rick Strahl did a great job documenting ASP.NET 2.0 threading model here
• Jeff Prosise and Fritz Onion wrote in-depth articles on the subject for 1.1 and 2.0 as well
• Here is an example showing how to create custom performance counters:
• PerfCounters.zip
• Here is an example illustrating some of the health monitoring configuration features of ASP.NET 2.0:
• HealthMonitoring.zip

I just added the federation sample to this blog entry: http://www.dasblonde.net/default.aspx#a0de3e38e-a516-4a33-a85d-3027a505f7b8

CardSpace anyone?

I did a session at Tech Ed on CardSpace (formerly known as InfoCard) that illustrated several ways to integrate CardSpace into your applications. For example you can:

1. Use CardSpace to pass claims to a web application using the <object> tag or XHTML (IE 7).
2. Use CardSpace to pass claims to a WCF web service using wsHttpBinding/IssuedToken credentials, or wsFederationHttpBinding and specifying a list of claims.
3. Use CardSpace to pass claims to a WCF security token service (STS or token issuer) that in turn validates those claims and issues a token for the target WCF service. This involves specifying an alternate token issuer, and implies that that token issuer might trust the CardSpace claims to issue a proper SAML token for the target service.

I have samples for all three, and the delay in posting (sorry) is related to writing up instructions to make sure you are successful...while I was out of town last week.

UPDATED: 06/28/06 to add federation sample

InfoCardBrowser.zip (18.27 KB)

InfoCardWSHttpBinding2.zip (1.98 MB)

MediaServicesFederation.zip (2.07 MB)

Oh, I should also mention that I had lots of help from several product team members to get these samples working on the latest build on short notice - both on the WCF and CardSpace teams...these guys really rock! And you might want to head to Martin Gudgin's blog for more Q&A on the STS he let me use for the federation sample!

Let me know if you have any questions after reading the readme files!