| Re: [higgins-dev] Attack on CardSpace possible with CloudSelector? |
Johnathan, Funny thing, I was just working up a similar idea to there second recommendation as part of adding holder of key proofs through a browser. The compromise of the browser they hypothesize is difficult. If someone can do that they can compromise a cloud selector as well. They simply modify the JS in the browser to post the token back to there server as well. It is probably easier. There are also no standards for invoking a cloud selector or for how the selector gets the certificate of the RP. I think the Higgins cloud selector would be compromised by performing a DNS attack on the selector service as the easiest route. This sort of MTM attack needs to be mitigated against at LoA 4, but anything up to LoA 3 is not required to mitigate agains it. The assumption up to LoA 3 is that the user is not a total fool and will notice the various SSL warnings. For LoA 4 there needs to be a connection between the channel and the proof key in the token. There proposal is on the right track but needs some changes in my opinion. The SSL Master Secret needs to be used to create a Holder of Key token with a symmetric proof proof key. It then becomes the responsibility of the RP to check that the proof key in the token matches the SSL master secret for the session the token is received over. John B. On 2010-03-27, at 10:28 PM, Jonathan Tellier wrote: > 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature