Microsoft's Geneva Server: Hailstorm done right

Microsoft just don't get it, do they...?

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...

@Pierre, @Tom Chiverton

"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.

Like the man said, "Anyone want to mention citizens' roles & rights?"

"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?

@Mickael Wojcik

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.

@Pierre

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.

Oh dear

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.