Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

I always enjoy working at technical conference booths when I get the opportunity to talk about security with people who are dealing with day-to-day issues on the front lines. This week at TechEd Developers in Barcelona did not disappoint! In fact, a variety of interesting topics were brought up by attendees when visiting the Security Development Lifecycle booth on the exhibition floor.

The one that most stuck in my mind was regarding phishing and CardSpace. Frankly, CardSpace marketing materials have been making some pretty bold claims about how the technology combats phishing, and one TechEd attendee was expressing some healthy skepticism. His question was regarding the use of CardSpace authentication in the context of a client browser connection over the internet. There was also a question about combating man-in-the-middle (MITM) attacks in that context, but I’m going to save that for another post.

Before reading on, I do recommend the CardSpace/MSDN link above. It’s an excellent introduction to the technology from a down-to-earth security perspective.

And before I get to my concerns, I want to emphasize that I believe that replacing passwords is the true value of CardSpace, and that it’s an important goal.

However, I disagree with that article on three points, most of which are touched upon in the “Improved User Confidence in the Identity of Web Applications” section.

First, the author seems to believe that “high-value” EV (Extended Validation) SSL certificates are an intrinsic feature of CardSpace, which they’re not. EV certs are what cause the Internet Explorer address bar to turn green, as an attempt to differentiate sites that have undergone additional vetting – the theory being that if you care enough about your reputation to shell out big bucks for an HV cert, you’re not a phisher. However, those two technologies – CardSpace and EV certs – are independent of each other. I can easily deploy EV certs without CardSpace and vice-versa.

EV is certainly an anti-phishing technology; I’m debating its efficacy. As an introduction, a sample scenario is this: a user gets a phishing email with a link they click on telling them that their bank needs some piece of data from them. The user clicks, taking him to a site that looks exactly like his real bank, except that it’s not. But he doesn’t notice that, so he types in his password anyway. Then the fake site simply redirects him to the real bank site, storing the captured password for subsequent use.

EV attempts to combat that problem by turning the address bar green when the user surfs to a site considered to be of high integrity (which, in the above example, the first one wouldn’t be). I’m just not convinced how effective it is. For one thing, how many users notice things like the fact that the address bar isn’t green? I mean, the address bar is almost never green, and now regular users are supposed to notice that? For another thing, it’s not clear to me how many online entities are going to pay big bucks for an EV server cert. For example, my business’s bank, which is about the farthest thing from small, doesn’t currently use one.

As an aside, some phishing sites are lazy enough to avoid getting even a basic valid SSL cert. In those cases, IE7 turns the address bar red and re-confirms before rendering the page. All goodness. But a slightly less lazy attacker will get a valid server cert and matching site name (e.g. one closely resembling that of your bank).

So I definitely would push any major deployment of CardSpace to also use EV certs. But the added expense of the latter means that the former will often be deployed without it.

Second, regarding my concerns about the above article, CardSpace introduces a mandatory user dialog prompt each time a new “relying partner” is encountered. See Figure 6 on that page. What does that mean? Basically, every time that user encounters a new CardSpace server identity, he’s going to be prompted to ensure that he believes that server is who it says it is.

I come from the school of thought that requiring users to make this kind of security decision is a losing proposition. I mean, if we assume based on the previous argument that the phishing site has acquired a valid (non-EV) SSL cert from a trusted provider, then that’s what the “relying partner” prompt is going to say: “Here’s the server identity. It’s valid, but it’s not EV. What do you want to do?” And what are users going to do? I think they’ll click, “Let’s party.” So the actual anti-phishing value of that prompting is debatable.

Third, and finally, I miss the days when technical documentation was really boring and factual and didn’t include any marketing or hype. Especially when you’re talking about a security feature, and the issues involved are subtle.

 

Permalink |

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment