Sorry, I should have been clearer.
In the Web selector case like for openID, and SAML POST binding you would want to compromise the Browsers DNS so that you can masquerade as the IdP/Webselector that way you can insert a SAME origin script from the IdP URL and compromise all of the tokens the user sends to any RP. So the attack would be compromising the IdP DNS in the browser by one of the known methods. I don't think this is a easy attack. Most Phishers are going to concentrate on easier targets. However as the value of the information protected by federated identity increases someone will try it. I think a cloud selector is a much better target for an attack because it compromises multiple RP all at once. I actually like the idea of cloud selectors, however a redirect based protocol is always going to be weaker, unless you are doing Holder of Key and at that point you have some active client anyway unless you are using mutual TLS everywhere with a single cert. Adding Holder of Key to the existing selector is the best option for a number of reasons in my opinion. John B. On 2010-03-28, at 7:18 PM, Jonathan Tellier wrote: > Hello, > > I think that what you say makes sense, but there's a part that I don't > understand: > >> I think the Higgins cloud selector would be compromised by performing a DNS >> attack on the selector service as the easiest route. > > Maybe I'm missing something, but I thought that the token does not go > directly to the RP. It is sent to the browser that then sends it to > the RP. Maybe I'm not getting the process right though... If the cloud > selector does not communicate directly to the RP, how would > compromising its DNS server help an attacker? > > Thanks, > Jonathan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
