InfoCard takes great pains to change the way that people interact with identity information so that they learn good security practice. That is a tall order in a world where users have been trained for years to click OK. Site does not match the certificate? OK. Site only works if you download something? OK. Site would like you to post your credentials over an unsecured transport? OK. Whoops, this site is guilty of that one at the moment. Feel free to mock.

While InfoCards cannot fix all potential security issues when people surf the internet, it does have the opportunity to fix some of them. Clearly Kim Cameron and his team have thought long and hard about the link in the security chain that is always the weakest: us. To save us from ourselves InfoCard first requires a secure transport in order to protect our information in transit. Second it darkens the screen around the applet, putting the user on notice that something security related is happening and to pay attention. Third it provides a single interface with which the user shall become accustomed and more likely to notice when it does not look quite the same. Fourth it represents the available identity information as groupings of claims in infocards which appear in the same order, have user entered descriptive text, and may be customized with a graphic. When put together it would appear that this is an almost impenetrable combination that would defy even the most talented spoofer.

However, the fine art of phishing, along with spamming, is one of the most pertinent examples of the benefits of scale. Both phishing and spamming are profitable because the effort of scaling is similar to the effort required for one attempted attack. One attack which has a high chance of failure is unfortunate but not a serious problem. Scale that to thousands or millions of attacks and the high chance of failure can be discounted because the small percentage of successes is all that is required to make the attack worth while.

With that in mind lets take a look at how we might play the numbers with InfoCards. I shall assume a compromised web browser process or some other method of executing unauthorized code. That might seem like a harsh test, but really it is simply a realistic one. Even when the user is running with limited privileges, as they should be, rarely do those privileges lack the ability to execute a process!

Secure transport

The only way the average user knows a secure transport is in use is by the application that they use making a claim that it is. A compromised process simply lies. Few, if any, users will break out the network sniffer and check.

Darkened screen

The same methods that allow games and screen savers to take control over the entire screen are available to a spoofing process. The interesting thing about this is that even the spoofer will be required to provide the cue to the user that they should be paying attention.

Familiar interface

A familiar interface is also familiar to the spoofer. By the same principal that the darkened screen spoofable, so are the mechanics of, and look and feel of the applet itself.

Customized data representation

This really should be the coup de grĂ¢ce. Having achieved spoofing all other aspects of the interface the spoofing process is now required to spoof the customized infocards. The problem for the spoofer is that there is no way to get at any information that would allow them to do so. No way at least if this were a single attack on a single target. As we already know, scaling reaps the rewards of the small probability. All the spoofer has to do is come up with a reasonable set of cards and play the numbers. Currently I see a flaw in the customization scheme that makes this easier to do: for the cards to have this property of customization the user must have previously taken action to do so. In their default state all infocards look the same. Guess what the spoofers will spoof - a non-customized self asserted card with a likely name (My info?).

Here’s my suggestion: make the default customization non-default. On creation of each infocard select at random a graphic from a sufficiently large available set and use that in the absence of direct user customization. This will substantially reduce the effectiveness of any attack based on playing the numbers for infocard spoofing.

You might ask what a spoofer could do once the user has been convinced that they are interacting with the InfoCard - after all, no data has been compromised at that point. Well, I will leave that to the spoofers, but it is not hard to conceive of ways to convince the user to give up information voluntarily. Simply by playing on the trust in a particular site that the interaction has engendered or through the spoofed interface itself the user could be duped. After all, users fall for less sophisticated attacks all the time. While we’re here, we might as well plug that hole.