XAuth critiques

Peter Watkins peterw at tux.org
Tue Jun 8 02:35:45 UTC 2010


On Mon, Jun 07, 2010 at 04:38:11PM -0700, John Panzer wrote:
> On Mon, Jun 7, 2010 at 2:27 PM, Peter Watkins <peterw at tux.org> wrote:
> > Do you mean that your current, centralized XAuth implementation doesn't
> > break
> > privacy, or that your "end game" desired XAuth would not break privacy?

> Both.

Thanks for clarifying.

> > > I think it would be great to have a discussion about privacy and security
> > > aspects of XAuth. Which should start with a discussion about what attacks
> > > we're worried about preventing, and how XAuth affects them.  As an
> > example,
> > > there could be a security concern that knowing that I have an active
> > session
> > > with Google may help phishers know which identity provider to simulate
> > when
> > > I go to their site.  Or, ....

> > Exactly. That's why I ask about "current" vs "end game". Do you think those
> > concerns are not significant enough to say that the current XAuth "breaks"
> > privacy
> > would defend against those attacks?

> I don't think they add significant risk to the status quo.  Note that it is
> today possible for a rogue RP and rogue IdP to collude to leak your identity
> with or without XAuth.  XAuth provides mechanisms to allow IdPs to whitelist
> the RPs they'll expose information to.

Whitelists again? Ugh. Chris had that nice video explaining how XAuth could
put a few IdPs up their in a short, relevant list of choices. Now you're 
saying to make privacy OK, IdPs have to whitelist RP sites? That sounds
like a mess, and like a much weaker and less interesting approach to improving
the UX than I expected. And why would the IdP be in the business of 
whitelisting? It's more likely, as I've said in other threads, that the
end user would want to control what information was sent to each RP.

> I think that browser support would make some
> things easier -- perhaps defending against "pretend" IdPs that use social
> engineering to get themselves on your IdP list -- but (a) those attacks
> aren't privacy issues and (b) they appear low value to me.

What social engineering? Getting you to open a page with an XAuth iframe?
That sounds like a relatively easy attack to carry out, esp. in the era
of tinyurl and bit.ly.

> I will agree that things would be more secure if we encased every client
> computer in concrete with no 'net connection and sank them to the bottom of
> the ocean.

Excuse me?

> > I haven't given a lot of thought to this, but it appears to me that the
> > current XAuth setup isn't some rough draft of an oversimplified account
> > management mechanism that could easily be extended or improved. It looks
> > to me like a pretty mature, feature-complete system. I mean, you seem
> > pretty
> > tied to some very specific HTML5 tech in XAuth

> No.  I'm envisioning that browsers would directly replace the higher-level
> JS API so there would be no postMessage() calls at all.  Why would there
> need to be?  The providers just need to call setters and the relying parties
> to call getters (or queriers).

Ah, looking at your (Google's) current XAuth materials, I don't get the
sense of this changing.

> > BTW, I think it's a little sad that Google is pushing this early
> > centralized
> > model for gaining "deployment experience" when you could bake this into
> > Chrome
> > and Firefox extensions (or even release custom builds of Firefox) to test
> > the
> > system with decentralized code.

> Sure, we could host extensions at xauth.org.  And then people could download
> them.  From, um, a centralized site.  How is that more decentralized
> exactly?

Users could vet the code and not worry about it changing on them the way it
could from a SaaS site like xauth.org. xauth.org would have no indication
whatsoever that a user was interacting with XAuth-compatible Extenders or
Receivers. And if you use a decent license (or write a nice spec), anyone
else could implement their own extension. Including IE extensions, I don't
know why I omitted IE from my list.

I'll post this on the xauth group now, too, but for instance currently the 
xauth.org site is not accessible via a https URL (at least not one that 
passes normal CN/hostname checks), so a malicious wifi hotspot operator 
could intercept traffic and do interesting things like read that shared 
LocalStorage even if all the normal RP and IdP traffic was https. Switch
to an in-browser model and that hole, and others, disappear.

-Peter



More information about the specs mailing list