Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] Attack on CardSpace possible with CloudSelector?

The attack described in the paper referenced is pretty unrealistic. CardSpace and Higgins use the RP's SSL certificate to encrypt the token. Even IF (A very big if) you can manipulate DNS entries in real-time and get a user's browser to land on two different sites with the same DNS entry on consecutive HTTPS Requests, they will have different SSL certificates and the token encrypted with the first site's key will be unusable on the second site.

Also, if you have such complete control over the user's machine that you can manipulate its DNS entries in real time, all bets are off wrt security. For instance, you could let the user's machine login to a site (without the "attack" described in the paper)  and then just hijack its connection to perform whatever transactions you like. This is not a CardSpace/Higgins/IMI specific problem.

Regards,
Michael McIntosh
VP Development
Azigo

-----Original Message-----
From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jonathan Tellier
Sent: Saturday, March 27, 2010 10:28 PM
To: Higgins (Trust Framework) Project developer discussions
Subject: [higgins-dev] Attack on CardSpace possible with CloudSelector?

Hello there,

I've recently stumbled upon a paper that describes an attack that can be made on CardSpace. The article can be downloaded here:
http://demo.nds.rub.de/cardspace/GaScXu08_CardSpaceTR.pdf.

To summarize briefly, after a successful DNS spoof attack, a malicious Web server is accessed when a user tries to visit a RP's site. The malicious server then redirects the user to the legit page, but breaks the "same origin policy". That makes it able to intercept the token that is sent to the RP by the card selector through the browser.

Basically, I was wondering if this attack is possible if the user is using the CloudSelector. It is my understanding that the token that comes from the selector and is sent to the RP passes through the browser, even though the selector is not running on the user's computer. If it's the case then the attack would be possible.

Am I missing something? Any thoughts?

Thanks,
Jonathan
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev


Back to the top