It may be so... but "It doesn't use cryptography, it just uses DNS. That means it's subject to all the attacks that DNS is subject to." sounds like marketting crap: everyone heard that a vuln in DNS has been discovered (and mostly patched, for now at least) so a marketting droid decided to spout "blah blah blah DNS vulnerability blah blah blah" in hope that people might think he knows his shit. As far as I can tell (which is not terribly far), once you've been MITMed, no encryption technique can save you. Unless of course you have pre-shared unique pairs of keys. Did MS come up with unique keys hard-coded in the browser so as to uniquely identify each copy of IE? They would need to create a unique key on their server for each copy of IE sold, too. Beforehand. Do they have that? I thought not. So their technique is just as vulnerable as any other. Anyone more up-to-speed with the subject care to prove me wrong?

"CardSpace has its own user interface, built into the browser, so it is hard for a phishing site to fake it"

When I've stopped laughing, I'll be able to ask you if you were awake when you wrote that... *Even if* MS has managed to build the imposable (a non spoofable GUI) what on Earth makes you think a user will be able to spot the different betwen the one 'built into the browser' and the very similar one embeded into the web page ?

Geez. And ti runs on spoofable DNS too. Handy.

Oh well. Another MS tech, to ignore, who prints this rubbish :-)

The reason Hailstorm failed, and CardSpace will fail as well, is because no one trusts Microsoft. No one wants Microsoft to take over identity management the way they took over the PC desktop.

So, that makes IT's life easier, then.

Microsoft just don't get it, do they? Content to flail around with their organization-centric, rear-guard protection of Active Directory. Anyone want to mention citizens' roles and rights?

No, I thought not. The business need comes second to demonstrating just how clever we can be and so, the myopic Microsoft muppet-fest rolls on.

Shame they didn't get all of TADAG squeezed into OpenID...

"As far as I can tell (which is not terribly far), once you've been MITMed, no encryption technique can save you. Unless of course you have pre-shared unique pairs of keys."

No, a MITM attack does not defeat all possible cryptographic protocols. If it did, there'd be no need for SSL/TLS, because they'd be entirely worthless (instead of merely mostly worthless, largely due to terrible user interaction).

Nor do you need "pre-shared unique pairs of keys". You need one pre-shared key: the public key for verifying a trusted CA's signature. Then the critical parties can pass around certificates signed by that CA to verify their identities, and that can be used to construct protocols for verifying someone else's identity.

And that's what Cardspace does. Bob goes to foo.com. foo.com says, "Prove you're Bob; we'll believe it if any of these third parties (STSs) that we trust vouch for you". Bob selects one of those third parties - he's already verified his identity to it, or he does so now - and the third party sends a token to foo.com. The token is signed by the third party, and that signature can be verified using the certificate chain back to the CA.

A MITM can watch those messages, but it never sees any private keys or other confidential information. (Bob's exchange with the STS can be protected in any of a number of ways, because it's a long-term, pre-established relationship.) It could modify the messages, but that would invalidate the signatures.

If foo.com is hostile, all it got was a token proving - to it - that Bob is Bob. It can't use that token for any other purposes. It never sees Bob's credentials, so *it* can't impersonate Bob.

Cardspace is sort of like a generalized Kerberos - not in the details of the protocols, but in the sense that you have one or more third parties that are trusted by the participants to verify a user's identity. Once you have that, users no longer need to send credentials to origin servers, and origin servers don't have to keep user credentials or verifiers (eg password hashes). It's a mechanism for transitive trust, plus a fairly nice UI on the client side.

And yes, Cardspace resists spoofing in the browser by web sites. When a server asks for a Cardspace identity, the UI displays a list of "cards", which represent identities the user has registered. Each card includes an image. Part of the idea is that the images are chosen by the user, so an attacker can't predict how any one card should look - much less how many cards the user might have, or what they should say. It's infeasible to guess.

Of course, a great many users are easily fooled, and a significant portion would probably be taken in by an HTML form with the caption "Hey, dumbass, enter your username and password here. PS this is Cardspace so you're totally safe". This is an unsolved problem in software design.

"Authentication" & "identity management" are meaningless without understanding the context of citizens' engagements and where they are required. The Canadians seem to have got a grip of this lesson for public sector use, so why is Microsoft still missing the point?

RE: "Cardspace resists spoofing in the browser by web sites. When a server asks for a Cardspace identity, the UI displays a list of "cards", which represent identities the user has registered. Each card includes an image. "

This is *exactly* what Yahoo has implemented in their OpenID provider to ensure that you can't be phished. You see an image that you uploaded, one that no phishing site will ever guess.

The BIG difference however is that you don't need IE (and don't tell me Cardspace works reliably in Firefox until you've tried it!) AND, get this, you can still login from any computer anywhere in the world without having to bring your cardspace IDs with you on a memory stick or however you are meant to transport them???

Cardspaces ties you right back to a PC running IE while OpenID works anywhere.

The only thing holding OpenID back is a lack of support by Google and Microsoft.

Once Google, Microsoft and Yahoo all support it, other sites will flock to it because it gives a better customer experience. So quit the fud about encryption and DNS attacks, go look at the Yahoo implementation of OpenID and compare that to Cardspaces. Now try logging in from your iPhone, friend's PC, or your Mac. Which one works everywhere?

Thanks for taking the time to answer, but you misunderstood my post. I (mostly) know how Cardspace works, and it's -mostly- how OpenID works too. My point was, once you're MITMed, especially at the DNS level, they both are useless. And SSL/TLS also is. Basically, all your data transit through an hostile system which pretends to be you for the outer world, and pretends to be the outer world to you. There is no way you can prevent it from seeing your data flux. Then it's just a matter of replicating parts of this flux when the victim disconnects (or to prevent the disconnection) and you're good to go. Both systems are equally vulnerable to a DNS attack. Of course the attacker can't see the info you registered with OpenID or Cardspace, but why would they need that? All your -online- life is belongs to them already!

I stick to my guns: mentionning DNS vulnerabilities here was pure marketting spin.

You dont appear to have understood Michael, or understand how cardspace works. A DNS attack will do nothing to help an attacker. If the attacker uses a DNS attack (not what would be a prefered method of attack for this but you suggested it), all that would happen is, no one would be able to authenticate, as the attackers server could not be authenticated by the client. Cardspace as said by Michael is just like kerberos, it performs mutual authentication, it makes sure the server is who it says it is and the server makes sure the client is who they say they are, so man in the middle attacks are thwarted.

>My point was, once you're MITMed, especially at the DNS level, they both are useless. And SSL/TLS also is.

How come ? Could you elaborate ? SSL/TLS uses certificates exactly to deny MITM attacks. That people will use non-https sites or may not know what to check when using their browser is another issue. If DNS is somehow f**ked up, SSL will fail and the Browser will alert the user.

Public Key Crypto is pointless if you can't defend against MITM. SSL seems to be technically very sound, assuming that the underlying crypto (RSA, 3DES, SHA etc) are not compromised, which is the public consensus. The TLS protocol has even be mathematically verified.

I think that a compromised client (Man In The PC, so to speak) is a much bigger issue.

IBM Zurich Labs did present something clever recently, a Trusted Minimal Hardware:

http://www.zurich.ibm.com/ztic/

Basically we cannot trust this complex machine (Linux, Mac, Windows, Firefox, IE etc). There must be a separate, simple and trusted piece of hardware, that can be formally verified for correctness. It NEEDS a minimal display and minimal input device.

Whatever the vulnerabilities, there needs to be consideration of the business context in which a solution is implemented. I hear lots of technical discussion without any real thought about where and when a customer / citizen might be receptive to deeper layers of security. If the context is accessing sensitive, personal data, then there are ways around DNS fallability. If it's for more general use, why would you bother? There needs to be much more thought too on the processes around mediated access for citizen services.

Of course, Microsoft has worked through all of this, their deeper concern being that anything (including TADAG / OpenID) that threatens the dominance of Active Directory, and the whole organization-centric security architecture that fuels Windows dependency, needs to be sponsored for devlopment in the bog lands of the beard and sandals brigade, from whence it is ever unlikely to emerge from the sticky mire of technical discussion...

So first off let's address the inaccuracies in the article.

CardSpace is not part of the browser; it's part of the operating system. The browser tells the OS to start it, and the OS brings it up, in a protected desktop, which does not accept system messages to fake keystrokes or mouse movements. This is part of how it protects against phishing. Also by using an OS component (or 3rd party implementation - the specs are open, and there are versions for Linux and the MacOS) it provides a consistent login experience; something which again is harder to fake.

There's no real requirement for the returned token to be encrypted, indeed for relying parties that do not have an SSL certificate the tokens are returned in plain text (although a selector must warn the user this is going to happen.

To address the comments then;

OpenID is horribly vulnerable to phishing; either via DNS exploits, or by simple redirect - when you try to login using OpenID you are relying on the accepting web site to redirect you to your OpenID provider - it can of course lie, and redirect you to a phishing site. Because Information Cards are utilising SSL, and WS-Secure/WS-Trust a simple MIM attack won't work; you'd need to spoof the certificates on the endpoints as well, a task that is an order of magnitude harder to do. If you have a way of spoofing SSL then frankly e-commerce is over.

For those who think Information Cards are linked to AD, IBM might tend to disagree, having beaten Microsoft to the punch and releasing an Information Card STS for their higgins metaverse months before Geneva arrived. At the end of the day what backs an STS is immaterial.